#343690 perl: segfault in perl_clone(), probably due to running out of memory

Package:
perl
Source:
perl
Description:
Larry Wall's Practical Extraction and Report Language
Submitter:
Jamil Djadala
Date:
2020-11-15 00:21:07 UTC
Severity:
normal
#343690#5
Date:
2005-12-17 09:17:53 UTC
From:
To:
Im write small test script to check how many threads can be run.
this script segfault,  i check on sarge i386 and etch and64, in all cases
kernel is 2.6 whith  nptl ( on sarge i386 package libc6-i686 is installed)

before running test, set vm.overcommit_memory=2 and vm.overcommit_ratio=100
otherwise system can be unresponsible due to swapping.

also setting "ulimit -s unlimited" only increase number of threads before
segfault



begin test script
#####################################################################
#!/usr/bin/perl -w

#sysctl -w vm.overcommit_memory=2
#sysctl -w vm.overcommit_ratio=100

use threads;
use threads::shared;
use strict;
use warnings;


my $a : shared;
my $n : shared;

sub incn {
   lock($n);
   $n++;
}

$a = 1;
$n = 0;

sub my_function {
   incn( $n);
   while ($a) {
      my $child_thread = threads->new(\&my_function);
      if($child_thread) {
         $child_thread->detach;
      }
      else {
         $a = 0;
      }
   }
}

#my_function();
my $c = threads->new(\&my_function);
$c->detach;
while( $a ) {
   print "$n\n";
   sleep( 1);
}
print "--$n--\n";
for( my $i=0; $i<10; $i++) {
  sleep(1);
  print "$n\n";
}
#####################################################################
end test script
#343690#10
Date:
2006-02-28 16:00:33 UTC
From:
To:
Hello,

the following snippet successfully crashes Perl in 2 of 3 times on a
XEON SMP system. On non-SMP, it may take few seconds..minutes with the
attached loop, but then it segfaults, sooner or later. Apparently it
segfaults sooner on Atlon64 (x86 mode). Some people on #debian-devel
could reproduce it well, others could not at all. No idea which context
is required to reproduce it.

#!/usr/bin/perl
#
sub flow {
#
        print "jo, ist da\n";
#
        sleep 20;
#
}
#
use threads;
#
my $thr = threads->new(\&flow);
$thr = threads->new(\&flow);

time while perl perl_crash.pl ; do : ; done
#343690#15
Date:
2008-05-11 19:35:01 UTC
From:
To:
This bug should be fixed in latest perl_5.10 with latest libc6_2.7
Please test it and reopen otherwise.



Ahora también puedes acceder a tu correo Terra desde el móvil.
Infórmate pinchando aquí.
#343690#20
Date:
2008-05-12 10:25:26 UTC
From:
To:
reopen 343690
found 343690 5.0.10-10
thanks
the first test script (the one by Jamil Djadala) in the report and
vm.overcommit_memory=2 on current sid: perl 5.10.0-10, glibc 2.7-11. The
kernel is from Etch, though, which actually might matter. Reopening
anyway.

The bug doesn't usually show up on the first try; see below.  It looks
like the system runs out of memory doing the perl_clone(), and something
can't quite cope. The resulting core file is obscenely big. The number
of Perl_*_dup calls and the final crashing place in the stack trace varies.

Roberto, do you know something more about this, or what was it that
prompted you to close the bug?

% debugperl ~/t.pl
sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
Out of memory!
sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
--76--
76
76
76

sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
zsh: segmentation fault (core dumped)  debugperl ~/t.pl

#0  0x00000000004833bf in S_more_bodies (my_perl=0x1d50da0, sv_type=SVt_PVAV) at sv.c:1065
#1  0x0000000000484536 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d88, param=0x40601c20) at sv.c:10106
#2  0x00000000004844b6 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d70, param=0x40601c20) at sv.c:10218
#3  0x00000000004845d0 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d58, param=0x40601c20) at sv.c:10304
#4  0x0000000000484413 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5bd8, param=0x40601c20) at sv.c:10305
#5  0x0000000000485605 in Perl_gp_dup (my_perl=0x1d50da0, gp=0x9c9fc8, param=0x40601c20) at sv.c:9738
#6  0x0000000000483e59 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5bc0, param=0x40601c20) at sv.c:10172
#7  0x000000000046c973 in Perl_he_dup (my_perl=0x1d50da0, e=0x9c02f8, shared=-96 ' ', param=0x40601c20)
    at hv.c:189
#8  0x0000000000484023 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5b90, param=0x40601c20) at sv.c:10247
#9  0x00000000004855ca in Perl_gp_dup (my_perl=0x1d50da0, gp=0x9c9df8, param=0x40601c20) at sv.c:9736
#10 0x0000000000483e59 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5b78, param=0x40601c20) at sv.c:10172
#11 0x000000000046c973 in Perl_he_dup (my_perl=0x1d50da0, e=0x9c02b0, shared=-32 'à', param=0x40601c20)
    at hv.c:189
#12 0x0000000000484023 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9605d8, param=0x40601c20) at sv.c:10247
#13 0x0000000000483e47 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9605c0, param=0x40601c20) at sv.c:10171
#14 0x0000000000498995 in perl_clone (proto_perl=0x91cda0, flags=2) at sv.c:11077
#15 0x00002b2f8a126244 in XS_threads_create (my_perl=0x91cda0, cv=<value optimized out>)
    at threads.xs:666
#16 0x0000000000479a78 in Perl_pp_entersub (my_perl=0x91cda0) at pp_hot.c:2847
#17 0x00000000004533f1 in Perl_runops_debug (my_perl=0x91cda0) at dump.c:1931
#18 0x0000000000472628 in Perl_call_sv (my_perl=0x91cda0, sv=0x9d5e08, flags=4) at perl.c:2653
#19 0x00002b2f8a127d6e in S_ithread_run (arg=<value optimized out>) at threads.xs:440
#20 0x00002b2f84787017 in start_thread () from /lib/libpthread.so.0
#21 0x00002b2f84a6154d in clone () from /lib/libc.so.6
#22 0x0000000000000000 in ?? ()
#343690#27
Date:
2008-05-12 10:25:26 UTC
From:
To:
reopen 343690
found 343690 5.0.10-10
thanks
the first test script (the one by Jamil Djadala) in the report and
vm.overcommit_memory=2 on current sid: perl 5.10.0-10, glibc 2.7-11. The
kernel is from Etch, though, which actually might matter. Reopening
anyway.

The bug doesn't usually show up on the first try; see below.  It looks
like the system runs out of memory doing the perl_clone(), and something
can't quite cope. The resulting core file is obscenely big. The number
of Perl_*_dup calls and the final crashing place in the stack trace varies.

Roberto, do you know something more about this, or what was it that
prompted you to close the bug?

% debugperl ~/t.pl
sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
Out of memory!
sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
--76--
76
76
76

sid% debugperl ~/t.pl
0
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
Thread creation failed: pthread_create returned 12 at /home/niko/t.pl
line 26.
zsh: segmentation fault (core dumped)  debugperl ~/t.pl

#0  0x00000000004833bf in S_more_bodies (my_perl=0x1d50da0, sv_type=SVt_PVAV) at sv.c:1065
#1  0x0000000000484536 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d88, param=0x40601c20) at sv.c:10106
#2  0x00000000004844b6 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d70, param=0x40601c20) at sv.c:10218
#3  0x00000000004845d0 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5d58, param=0x40601c20) at sv.c:10304
#4  0x0000000000484413 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5bd8, param=0x40601c20) at sv.c:10305
#5  0x0000000000485605 in Perl_gp_dup (my_perl=0x1d50da0, gp=0x9c9fc8, param=0x40601c20) at sv.c:9738
#6  0x0000000000483e59 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5bc0, param=0x40601c20) at sv.c:10172
#7  0x000000000046c973 in Perl_he_dup (my_perl=0x1d50da0, e=0x9c02f8, shared=-96 ' ', param=0x40601c20)
    at hv.c:189
#8  0x0000000000484023 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5b90, param=0x40601c20) at sv.c:10247
#9  0x00000000004855ca in Perl_gp_dup (my_perl=0x1d50da0, gp=0x9c9df8, param=0x40601c20) at sv.c:9736
#10 0x0000000000483e59 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9c5b78, param=0x40601c20) at sv.c:10172
#11 0x000000000046c973 in Perl_he_dup (my_perl=0x1d50da0, e=0x9c02b0, shared=-32 'à', param=0x40601c20)
    at hv.c:189
#12 0x0000000000484023 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9605d8, param=0x40601c20) at sv.c:10247
#13 0x0000000000483e47 in Perl_sv_dup (my_perl=0x1d50da0, sstr=0x9605c0, param=0x40601c20) at sv.c:10171
#14 0x0000000000498995 in perl_clone (proto_perl=0x91cda0, flags=2) at sv.c:11077
#15 0x00002b2f8a126244 in XS_threads_create (my_perl=0x91cda0, cv=<value optimized out>)
    at threads.xs:666
#16 0x0000000000479a78 in Perl_pp_entersub (my_perl=0x91cda0) at pp_hot.c:2847
#17 0x00000000004533f1 in Perl_runops_debug (my_perl=0x91cda0) at dump.c:1931
#18 0x0000000000472628 in Perl_call_sv (my_perl=0x91cda0, sv=0x9d5e08, flags=4) at perl.c:2653
#19 0x00002b2f8a127d6e in S_ithread_run (arg=<value optimized out>) at threads.xs:440
#20 0x00002b2f84787017 in start_thread () from /lib/libpthread.so.0
#21 0x00002b2f84a6154d in clone () from /lib/libc.so.6
#22 0x0000000000000000 in ?? ()
#343690#32
Date:
2008-05-12 13:50:46 UTC
From:
To:
Niko Tyni wrote:
very probably 5.0.10-10 has the bug, but does 5.10.0-10 have it? :P

I just wanted to know if this bug was still applicable to latests
versions.

Is this bug already known by upstream perl developers?



Ahora también puedes acceder a tu correo Terra desde el móvil.
Infórmate pinchando aquí.
#343690#41
Date:
2008-05-12 15:41:46 UTC
From:
To:
Thanks for noting, fixed.

Next time, please consider pinging the submitter+maintainer first rather
than blindly closing the bug.

No, it probably hasn't been forwarded upstream yet. I'll do that, this
is the first time I properly looked into it. The perl bug backlog has
got quite long, but I am working on that...
#343690#48
Date:
2008-05-26 13:16:03 UTC
From:
To:
severity 343690 normal
thanks

This is basically a thread version of a fork bomb that segfaults when
it runs out of memory. I think the severity is overrated, so downgrading.