From apocalypse@0ne.us

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
  .

From @iabyn

On Thu, Jan 15, 2004 at 11​:35​:46AM -0000, apocalypse@​0ne.us (via RT) wrote​:

# New Ticket Created by apocalypse@​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

The RT System itself - Status changed from 'new' to 'open'

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

From @iabyn

On Sat, Jan 17, 2004 at 04​:37​:25PM +0000, Dave Mitchell wrote​:

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.....

From perl5-porters@ton.iguana.be

In article <20040117170701.GD14442@​_disolutions.com>,
  Dave Mitchell <davem@​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) ?

From @iabyn

On Sat, Jan 17, 2004 at 05​:14​:42PM +0000, Ton Hospel wrote​:

In article <20040117170701.GD14442@​_disolutions.com>,
Dave Mitchell <davem@​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) ?

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.

From @rgs

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.)

From @iabyn

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!

Dave.

--
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
  (with apologies to William Blake)

From @rgs

Dave Mitchell wrote​:

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.

From @iabyn

On Sun, Jan 18, 2004 at 12​:20​:10AM +0000, Dave Mitchell wrote​:

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.