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

p5pRT · 2000-01-24T16:11:30Z

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

Searchable as RT2028$

p5pRT · 2000-01-24T16:11:30Z

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 · 2000-01-24T19:48:52Z

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 · 2000-01-24T21:53:35Z

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 · 2000-01-24T22:36:31Z

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 · 2000-01-25T11:44:46Z

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 · 2000-01-25T12:10:00Z

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 · 2000-01-25T14:26:08Z

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 · 2000-01-25T15:02:34Z

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 · 2003-04-23T00:14:05Z

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 · 2003-04-23T00:14:06Z

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

p5pRT closed this as completed Apr 23, 2003

p5pRT added Not a Bug Severity Medium distro-freebsd labels Oct 18, 2019

p5pRT mentioned this issue Oct 19, 2019

Program terminated with signal 11, Segmentation fault. #12469

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

p5pRT commented Jan 24, 2000

p5pRT commented Jan 24, 2000

p5pRT commented Jan 24, 2000

p5pRT commented Jan 24, 2000

p5pRT commented Jan 24, 2000

p5pRT commented Jan 25, 2000

p5pRT commented Jan 25, 2000

p5pRT commented Jan 25, 2000

p5pRT commented Jan 25, 2000

p5pRT commented Apr 23, 2003

p5pRT commented Apr 23, 2003

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

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

Comments

p5pRT commented Jan 24, 2000

p5pRT commented Jan 24, 2000

From larse@ISI.EDU

p5pRT commented Jan 24, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 24, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 24, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 23, 2003

From @iabyn

p5pRT commented Apr 23, 2003