Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.9k stars 538 forks source link

"perl in malloc(): warning: recursive call" on array write + signals #1075

Closed p5pRT closed 21 years ago

p5pRT commented 24 years ago

Migrated from rt.perl.org#2028 (status was 'resolved')

Searchable as RT2028$

p5pRT commented 24 years ago

From larse@ISI.EDU

Running the following test script causes perl to crash. You may need to run the script several times before seeing the problem. (The script spawns a child process that does nothing but write to an array. The parent signals the child periodically.)

#!/usr/local/bin/perl -w

use strict;

use constant CHUNK_SIZE => 128; use constant ARRAY_SIZE => 1_000_000;

$| = 1;

if(my $pid = fork) {   # parent signals periodically   while(1) {   select undef\, undef\, undef\, 0.1;   kill(ALRM => $pid) == 1 or die "cannot signal​: $!";   print ".";   } } else {   # is kid up?   unless(defined $pid) { die "cannot fork​: $!"; }  
  # initialize array (by using last element)   my @​data;   $data[ARRAY_SIZE] = 1;  
  # state of the process (number of alarms received)   my $state = 0;   $SIG{ALRM} = sub { $state++ };  
  # run the test   while(1) {   # calculate new position for this iteration   my $pos = int rand ARRAY_SIZE;  
  # write a chunk to a random position   @​data[$pos..$pos+CHUNK_SIZE] = (1) x CHUNK_SIZE;   } }

Execution of this script results in the following output​:

[sub​: ~/thesis/bin] short ......................perl in malloc()​: warning​: recursive call. Out of memory! ....perl in malloc()​: warning​: recursive call. Out of memory! perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl in free()​: warning​: recursive call. perl.perl in malloc()​: warning​: recursive call. Out of memory! perl in free()​: warning​: recursive call. cannot signal​: No such process at short line 14. Exit 3

Please let me know if I can provide any other information to help track this bug down.

Perl Info ``` Site configuration information for perl 5.00503: Configured by markm at $Date: 1999/05/05 19:42:40 $. Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=freebsd, osvers=4.0-current, archname=i386-freebsd uname='freebsd freefall.freebsd.org 4.0-current freebsd 4.0-current #0: $Date: 1999/05/05 19:42:40 $' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='undef', gccversion=egcs-2.91.66 19990314 (egcs-1.1.2 release) cppflags='' ccflags ='' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E' libpth=/usr/lib libs=-lm -lc -lcrypt libc=/usr/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so.3 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fpic', lddlflags='-shared' Locally applied patches: @INC for perl 5.00503: /usr/libdata/perl/5.00503/mach /usr/libdata/perl/5.00503 /usr/local/lib/perl5/site_perl/5.005/i386-freebsd /usr/local/lib/perl5/site_perl/5.005 . Environment for perl 5.00503: HOME=/nfs/ruby/larse LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/home/d7unsupp/FreeBSD.ELF/bin:/usr/local/v6/bin:/usr/local/v6/sbin:/usr/inet6/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11R6/bin:/usr/tmp/scotty/bin:/stand PERL_BADLANG (unset) SHELL=/bin/ntcsh ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Lars Eggert writes​:

Running the following test script causes perl to crash. You may need to run the script several times before seeing the problem. (The script spawns a child process that does nothing but write to an array. The parent signals the child periodically.)

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

$SIG{ALRM} = sub { $state++ };

One should not do anything as bad as that in a sighandler. What is the failure rate you see? You may get slightly better rate (3% in my tests) with something like

$SIG{ALRM} = sub { ++$state ; return };

and preallocating

  $state = 0;

Ilya

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Ilya\,

thanks for the quick response.

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.

Lars ____________________________________________________________________________ Lars Eggert \larse@​isi\.edu Information Sciences Institute http​://www.isi.edu/~larse/ University of Southern California

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Mon\, Jan 24\, 2000 at 09​:53​:27PM -0800\, Lars Eggert wrote​:

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

Never?

Never. Well\, I did not try XSUB signal handlers\, but if it is a Perl subroutine\, then the harm may be already done *before* the subroutine starts.

Ilya

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Mon\, 24 Jan 2000\, Lars Eggert wrote​:

Ilya\,

thanks for the quick response.

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.

Our malloc can't be used in a signal handler.

Lars ____________________________________________________________________________ Lars Eggert \larse@​isi\.edu Information Sciences Institute http​://www.isi.edu/~larse/ University of Southern California

To Unsubscribe​: send mail to majordomo@​FreeBSD.org with "unsubscribe freebsd-current" in the body of the message


Chuck Robey | Interests include C & Java programming\, FreeBSD\, chuckr@​picnic.mat.net | electronics\, communications\, and signal processing.

New Year's Resolution​: I will not sphroxify gullible people into looking up fictitious words in the dictionary.


p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Tue\, Jan 25\, 2000 at 02​:44​:05PM -0500\, Chuck Robey wrote​:

On Mon\, 24 Jan 2000\, Lars Eggert wrote​:

Ilya\,

thanks for the quick response.

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.

Our malloc can't be used in a signal handler.

One can write a signal handler in such a way that no mallocs are going to be called (see my example). But this would not help​: segfaults will happen anyway.

Ilya

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Tue\, 25 Jan 2000\, Ilya Zakharevich wrote​:

On Tue\, Jan 25\, 2000 at 02​:44​:05PM -0500\, Chuck Robey wrote​:

On Mon\, 24 Jan 2000\, Lars Eggert wrote​:

Ilya\,

thanks for the quick response.

Signals and Perl do not mix. Please do not use signals if a segfault is not a desirable form of output.

Never? After reading perlipc I was under the impression that using signals was okay if you keep your handlers simple. I may have to use to another form of IPC if signals cannot be made safe.

Our malloc can't be used in a signal handler.

One can write a signal handler in such a way that no mallocs are going to be called (see my example). But this would not help​: segfaults will happen anyway.

Do you know for a fact that perl\, in the signal handler code\, is not calling malloc?


Chuck Robey | Interests include C & Java programming\, FreeBSD\, chuckr@​picnic.mat.net | electronics\, communications\, and signal processing.

New Year's Resolution​: I will not sphroxify gullible people into looking up fictitious words in the dictionary.


p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Tue\, Jan 25\, 2000 at 05​:25​:40PM -0500\, Chuck Robey wrote​:

Do you know for a fact that perl\, in the signal handler code\, is not calling malloc?

$a = 0; # Prealloc the numeric slot; $SIG{FOO} = sub { ++$a; return };

will not call malloc()/free()/realloc(). [At least around 5.004].

But this is easy to check. Before the programs starts to recieve signals\, let it make call some obscure function. I usually do

  binmode STDERR;

or some such. Set breakpoint in Perl_pp_binmode. When hit (this way all the hard memory-allocation part is already done\, so you will not get false positives)\, set breakpoints in malloc\, free\, realloc\, and Perl_sighandler. Watch your results (continue after each breakpoint).

Ilya

p5pRT commented 21 years ago

From @iabyn

(I'm just reviewing old Perl bug reports).

Since Perl 5.8.0\, sygnal handling has become "safe"\, ie the C-level sigbnal handler just sets a flag then return; and Perl doesn't call the Perl-level signal handler until after the current Perl op has finished.

So presumably your problem is now resolved.

Regards\,

Dave M.

p5pRT commented 21 years ago

@iabyn - Status changed from 'open' to 'resolved'