[perl #24914] Segmentation fault in perl 5.8.2
perlbug-...@perl.org
# Please include the string: [perl #24914]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24914 >
After some narrowing down, I've produced a minimal case that will always
segfault. Sky told me to try build a non-threaded perl, but alas my box
doesn't have enough HD space to try it out, so I now give the problem to
ya'll :)
Here's the code:
# Standard stuff to catch errors
use strict qw(subs vars refs); # Make sure we can't mess up
use warnings FATAL => 'all'; # Enable warnings to catch errors
# Load some stuff
use POE;
use POE::Component::SimpleDBI;
# Fire off the SimpleDBI stuff
POE::Component::SimpleDBI->new(
'ALIAS' => 'SimpleDBI',
# Be sure to put something totally non-real in here
# Hint: put in a real database, but get the username+password wrong
'DSN' => 'DBI:mysql:database=NonExistant;host=192.168.1.1;port=3306',
'USERNAME' => 'TEST',
'PASSWORD' => 'TEST',
) or die 'Unable to create the SimpleDBI session';
POE::Kernel->run();
# Now, it should hang for a little bit, just wait for DBI to fail...
# Here's the exact line in SimpleDBI that causes perl to die:
# die( "Could not connect to the DataBase: $_[ARG0]->{'ERROR'}" );
# Now, IT SEGFAULTS on my debian testing box ( Perl 5.8.2 with threading )
__END__
Luckily, I got the perl-debug package, so here's a nice backtrace of the
segfault:
gdb --args /usr/bin/debugperl /test.pl
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 10629)]
0x0811f4b6 in Perl_leave_scope (my_perl=0x81a7df8, base=0) at scope.c:902
902 scope.c: No such file or directory.
in scope.c
(gdb) bt
#0 0x0811f4b6 in Perl_leave_scope (my_perl=0x81a7df8, base=0) at scope.c:902
#1 0x0811cb32 in Perl_pop_scope (my_perl=0x81a7df8) at scope.c:137
#2 0x0806b9e9 in S_my_exit_jump (my_perl=0x81a7df8) at perl.c:4524
#3 0x0806b67f in Perl_my_failure_exit (my_perl=0x81a7df8) at perl.c:4504
#4 0x08125b01 in Perl_die_where (my_perl=0x81a7df8,
message=0x8698f90 "POE::Component::SimpleDBI tried 5 times to create a
Wheel and is giving up... at
/usr/local/share/perl/5.8.2/POE/Component/SimpleDBI.pm line 466.\n",
msglen=146) at pp_ctl.c:1388
#5 0x080c7075 in Perl_vdie (my_perl=0x81a7df8, pat=0x8193e57 "%_",
args=0xbffffb50) at util.c:1099
#6 0x080c7188 in Perl_die (my_perl=0x81a7df8, pat=0x8193e57 "%_") at
util.c:1129
#7 0x08130e5f in Perl_pp_die (my_perl=0x81a7df8) at pp_sys.c:510
#8 0x080c40a3 in Perl_runops_debug (my_perl=0x81a7df8) at dump.c:1438
#9 0x080654ce in S_run_body (my_perl=0x81a7df8, oldscope=1) at perl.c:1860
#10 0x08064f11 in perl_run (my_perl=0x81a7df8) at perl.c:1779
#11 0x0805fc68 in main (argc=2, argv=0xbffffd94, env=0xbffffda0) at
perlmain.c:86
Running on Debian Testing ( 2.4.18-bf24 kernel )
perl -V shows:
Summary of my perl5 (revision 5.0 version 8 subversion 2) configuration:
Platform:
osname=linux, osvers=2.4.22-xfs+ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.22-xfs+ti1211 #1 sat oct 25 10:11:37 est 2003
i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.8.2 -Darchlib=/usr/lib/perl/5.8.2
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.8.2
-Dsitearch=/usr/local/lib/perl/5.8.2 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.2 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.2 (Debian)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.2
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Nov 15 2003 17:52:08
@INC:
/etc/perl
/usr/local/lib/perl/5.8.2
/usr/local/share/perl/5.8.2
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8.2
/usr/share/perl/5.8.2
/usr/local/lib/site_perl
.
Dave Mitchell
> # New Ticket Created by apoca...@0ne.us
> # Please include the string: [perl #24914]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24914 >
>
>
> After some narrowing down, I've produced a minimal case that will always
> segfault. Sky told me to try build a non-threaded perl, but alas my box
> doesn't have enough HD space to try it out, so I now give the problem to
> ya'll :)
Which can be reduced further to:
sub mydie { die }
my $f;
$f = sub {
my $x = 1;
$f = 0;
mydie;
};
$f->();
deleting $f's reference to the anon sub while it's active causes nasty
things to happen, principally because various savestack restores do stuff
to the now freed pad.
Fixed in bleedperl by patch #22167
Dave.
--
This is a great day for France!
-- Nixon at Charles De Gaulle's funeral
Dave Mitchell
> Which can be reduced further to:
>
> sub mydie { die }
>
> my $f;
> $f = sub {
> my $x = 1;
> $f = 0;
> mydie;
> };
> $f->();
>
> deleting $f's reference to the anon sub while it's active causes nasty
> things to happen, principally because various savestack restores do stuff
> to the now freed pad.
Note to self: the real problem is the winding down through the contexts
during the die - all the contexts are popped first, including the sub
context that holds a ref to the anon CV - thus causing it and it's pad
to be freed. Only then is the savestack popped, which tries to restore
lexicals etc in the now vanished pad. In an ideal world the individual
context popping would be interspersed with the scope popping, but since
contexts don't record PL_scopestack_ix, this isn't possible.
--
Thank God I'm an atheist.....
Ton Hospel
Dave Mitchell <da...@fdisolutions.com> writes:
> Note to self: the real problem is the winding down through the contexts
> during the die - all the contexts are popped first, including the sub
> context that holds a ref to the anon CV - thus causing it and it's pad
> to be freed. Only then is the savestack popped, which tries to restore
> lexicals etc in the now vanished pad. In an ideal world the individual
> context popping would be interspersed with the scope popping, but since
> contexts don't record PL_scopestack_ix, this isn't possible.
>
How about incrementing the refcount on the codereference in case of an
indirect function call (and decreasing it on return of course) ?
Dave Mitchell
Thats already happens - the refcnt of a CV is incremented when it is
called, and decremented upon return. Its just the order in which die
unwinds things that causes problems.
--
Never do today what you can put off till tomorrow.
Rafael Garcia-Suarez
>
> Fixed in bleedperl by patch #22167
Weird. The test you added to closure.t seems to hang randomly and unreproducibly,
entering an infinite loop. (If I see this again I'll try to produce a core.)
Dave Mitchell
It gets stuck in the system malloc library.
Using Perl's malloc it segfaults, so the patch clearly didn't fix the
original problem. I've retracted the whole patch for the time being.
Who knows, perhaps the mysterious op/write.t failures will go away too!
Dave.
--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
(with apologies to William Blake)
Rafael Garcia-Suarez
> On Sat, Jan 17, 2004 at 10:32:16PM +0100, Rafael Garcia-Suarez wrote:
> > Dave Mitchell wrote:
> > >
> > > Fixed in bleedperl by patch #22167
> >
> > Weird. The test you added to closure.t seems to hang randomly and unreproducibly,
> > entering an infinite loop. (If I see this again I'll try to produce a core.)
>
> It gets stuck in the system malloc library.
> Using Perl's malloc it segfaults, so the patch clearly didn't fix the
> original problem. I've retracted the whole patch for the time being.
> Who knows, perhaps the mysterious op/write.t failures will go away too!
Doubtful. On linux, at patchlevel 22172, with -Dusemorebits :
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
op/write.t 86 1 1.16% 44
With default config options, all tests passes.
Dave Mitchell
> On Sat, Jan 17, 2004 at 10:32:16PM +0100, Rafael Garcia-Suarez wrote:
> > Dave Mitchell wrote:
> > >
> > > Fixed in bleedperl by patch #22167
> >
> > Weird. The test you added to closure.t seems to hang randomly and unreproducibly,
> > entering an infinite loop. (If I see this again I'll try to produce a core.)
>
> It gets stuck in the system malloc library.
> Using Perl's malloc it segfaults, so the patch clearly didn't fix the
> original problem. I've retracted the whole patch for the time being.
Now fixed by change #22182. Entering a sub now incs the refcnt on the CV
*twice*: one is undone when the context is popped, the other when the
savestack is popped. This avoids premature freeing of the CV (and its pad)
during dounwind, which unwinds *all* contexts before processing the
savestack. In theory the correct solution is to get dounwind to
intersperse the two, but I couldn't get that to work.
Dave.
--
"Foul and greedy Dwarf - you have eaten the last candle."
-- "Hoardes of the Things", BBC Radio.