Mailing List Archive: Perl: porters

[perl #112312] perl5 version 5.14.2 coredumps during perl -c

Index | Next | Previous | View Threaded

perlbug-followup at perl

Apr 6, 2012, 1:27 PM

Post #1 of 16 (217 views)
Permalink

[perl #112312] perl5 version 5.14.2 coredumps during perl -c

On Fri Apr 06 10:59:31 2012, azus wrote:
>
> This is a bug report for perl from andrej.zverev [at] gmail,
> generated with the help of perlbug 1.39 running under perl 5.14.2.
>
>
> -----------------------------------------------------------------
> [Please describe your issue here]
>
> 5.14 coredumps during perl -c for me with following scripts.
> with perl 5.10, 5.12 perl -c show only syntax errors as it must be.
> I don't checked it with version > 5.14.2
>
> Try to run one of the two scripts, one of them should crash perl.
>
> # --- script #1
> #!/usr/bin/perl
> use strict;
> use warnings;
> sub meow (&);
> my %h;
> my $k;
>
> meow {
> my $t : need_this;
> $t = {
> size => $h{$k}{size};
> used => $h{$k}(used}
> };
> };

It appears there are two syntax errors here. If $t is a hash reference,
then there should be a comma after {size} -- not a semicolon. And
'(used}' probably should be '{used},'.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: new
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312

perlbug-followup at perl

Apr 6, 2012, 10:59 AM

Post #2 of 16 (206 views)
Permalink

[perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

# New Ticket Created by Andrej Zverev
# Please include the string: [perl #112312]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312 >

This is a bug report for perl from andrej.zverev [at] gmail,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
[Please describe your issue here]

5.14 coredumps during perl -c for me with following scripts.
with perl 5.10, 5.12 perl -c show only syntax errors as it must be.
I don't checked it with version > 5.14.2

Try to run one of the two scripts, one of them should crash perl.

# --- script #1
#!/usr/bin/perl
use strict;
use warnings;
sub meow (&);
my %h;
my $k;

meow {
my $t : need_this;
$t = {
size => $h{$k}{size};
used => $h{$k}(used}
};
};
# --- end of script #1

# --- script #2
#!/usr/bin/perl

use strict;
use warnings;

sub meow (&);

my %h;
my $k;

meow {
my $t : need_this;
$t = {
size => $h{$k}{size};
used => $h{$k}(used}
};
};

sub testo {
my $value = shift;
print;
print;
print;
1;
}

# --- end of script #2
or links:
script #1: https://gist.github.com/2318879
script #2: https://gist.github.com/2319125

results look like this:
# perl -c script(1|2).pl
Segmentation fault (core dumped)

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
Site configuration information for perl 5.14.2:

Configured by azverev at Wed Apr 4 07:36:27 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:

Platform:
osname=freebsd, osvers=8.3-rc2, archname=amd64-freebsd
uname='freebsd bz1s2.balancers.o3.ru 8.3-rc2 freebsd 8.3-rc2 #1: wed apr 4 06:23:55 utc 2012 azverev [at] bz1s2:usrobjusrsrcsysgeneric amd64 '
config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.14.2/mach -Dprivlib=/usr/local/lib/perl5/5.14.2 -Dman3dir=/usr/local/lib/perl5/5.14.2/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.14.2/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.14.2 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.14.2/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dinc_version_list=none -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.14.2/BSDPAN" -Doptimize=-O2 -pipe -fno-strict-aliasing -Ui_gdbm -Dusethreads=n -Dusemymalloc=n -Duse64bitint'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.14.2/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector',
optimize='-O2 -pipe -fno-strict-aliasing',
cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.14.2/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.2.2 20070831 prerelease [FreeBSD]', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags ='-pthread -Wl,-E -fstack-protector -L/usr/local/lib'
libpth=/usr/lib /usr/local/lib
libs=-lm -lcrypt -lutil
perllibs=-lm -lcrypt -lutil
libc=, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.14.2/mach/CORE'
cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector'

Locally applied patches:

---
@INC for perl 5.14.2:
/usr/local/lib/perl5/5.14.2/BSDPAN
/usr/local/lib/perl5/site_perl/5.14.2/mach
/usr/local/lib/perl5/site_perl/5.14.2
/usr/local/lib/perl5/5.14.2/mach
/usr/local/lib/perl5/5.14.2
.

---
Environment for perl 5.14.2:
HOME=/home/azverev
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/azverev/bin
PERL_BADLANG (unset)
SHELL=/bin/csh

perlbug-comment at perl

Apr 6, 2012, 1:34 PM

Post #3 of 16 (204 views)
Permalink

[perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

> It appears there are two syntax errors here. If $t is a hash reference,
> then there should be a comma after {size} -- not a semicolon. And
> '(used}' probably should be '{used},'.
>
Yes, there are two syntax errors but this is not a reason for segfault. Since 5.10 and 5.12 eat this
fine.

perl at profvince

Apr 6, 2012, 1:43 PM

Post #4 of 16 (213 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On 06/04/2012 22:27, James E Keenan via RT wrote:
> It appears there are two syntax errors here. If $t is a hash reference,
> then there should be a comma after {size} -- not a semicolon. And
> '(used}' probably should be '{used},'.
>
> Thank you very much.
> Jim Keenan
>
> ---
> via perlbug: queue: perl5 status: new
> https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312
>

perl shouldn't crash, regardless of whether the code is valid or not.

I can confirm the segfault with a perl built with PERL_POISON defined
(otherwise my system's libc isn't sensitive enough to catch it). 5.12.4
doesn't crash, but 5.14.2, 5.15.3 and 5.15.6 do. Here's a stacktrace for
perl 5.14.2 :

$ gdb --args perl5.14.2-dbg-psn-thr-64 x.pl
GNU gdb (Gentoo 7.4 p1) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from
/home/vince/perl/builds/bin/perl5.14.2-dbg-psn-thr-64...done.
(gdb) r
Starting program:
/home/vince/perl/builds/bin/perl5.14.2-dbg-psn-thr-64 x.pl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00000000004d7e84 in Perl_pad_free (my_perl=0xa86010, po=11354992)
at pad.c:1498
1498 if (PL_curpad[po] && PL_curpad[po] != &PL_sv_undef) {
(gdb) bt
#0 0x00000000004d7e84 in Perl_pad_free (my_perl=0xa86010, po=11354992)
at pad.c:1498
#1 0x000000000041dff2 in Perl_op_clear (my_perl=0xa86010, o=0xab8aa0)
at op.c:713
#2 0x000000000041d9d9 in Perl_op_free (my_perl=0xa86010, o=0xab8aa0)
at op.c:528
#3 0x00000000004d02a1 in Perl_yyparse (my_perl=0xa86010, gramtype=258)
at perly.c:678
#4 0x00000000004529aa in S_parse_body (my_perl=0xa86010, env=0x0,
xsinit=0x41cf02 <xs_init>) at perl.c:2194
#5 0x0000000000450a30 in perl_parse (my_perl=0xa86010,
xsinit=0x41cf02 <xs_init>, argc=2, argv=0x7fffffffde88, env=0x0)
at perl.c:1613
#6 0x000000000041ce45 in main (argc=2, argv=0x7fffffffde88,
env=0x7fffffffdea0) at perlmain.c:118

Vincent.

perlbug-followup at perl

Apr 6, 2012, 5:44 PM

Post #5 of 16 (209 views)
Permalink

[perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

perlbug-followup at perl

Apr 6, 2012, 11:36 PM

Post #6 of 16 (210 views)
Permalink

[perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Fri Apr 06 13:43:56 2012, perl [at] profvince wrote:
> On 06/04/2012 22:27, James E Keenan via RT wrote:
> > It appears there are two syntax errors here. If $t is a hash reference,
> > then there should be a comma after {size} -- not a semicolon. And
> > '(used}' probably should be '{used},'.
> >
> > Thank you very much.
> > Jim Keenan
> >
> > ---
> > via perlbug: queue: perl5 status: new
> > https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312
> >
>
> perl shouldn't crash, regardless of whether the code is valid or not.
>
> I can confirm the segfault with a perl built with PERL_POISON defined
> (otherwise my system's libc isn't sensitive enough to catch it). 5.12.4
> doesn't crash, but 5.14.2, 5.15.3 and 5.15.6 do. Here's a stacktrace for
> perl 5.14.2 :
>
> $ gdb --args perl5.14.2-dbg-psn-thr-64 x.pl
> GNU gdb (Gentoo 7.4 p1) 7.4
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.gentoo.org/>...
> Reading symbols from
> /home/vince/perl/builds/bin/perl5.14.2-dbg-psn-thr-64...done.
> (gdb) r
> Starting program:
> /home/vince/perl/builds/bin/perl5.14.2-dbg-psn-thr-64 x.pl
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004d7e84 in Perl_pad_free (my_perl=0xa86010, po=11354992)
> at pad.c:1498
> 1498 if (PL_curpad[po] && PL_curpad[po] != &PL_sv_undef) {
> (gdb) bt
> #0 0x00000000004d7e84 in Perl_pad_free (my_perl=0xa86010,
po=11354992)
> at pad.c:1498
> #1 0x000000000041dff2 in Perl_op_clear (my_perl=0xa86010,
o=0xab8aa0)
> at op.c:713
> #2 0x000000000041d9d9 in Perl_op_free (my_perl=0xa86010, o=0xab8aa0)
> at op.c:528
> #3 0x00000000004d02a1 in Perl_yyparse (my_perl=0xa86010,
gramtype=258)
> at perly.c:678
> #4 0x00000000004529aa in S_parse_body (my_perl=0xa86010, env=0x0,
> xsinit=0x41cf02 <xs_init>) at perl.c:2194
> #5 0x0000000000450a30 in perl_parse (my_perl=0xa86010,
> xsinit=0x41cf02 <xs_init>, argc=2, argv=0x7fffffffde88, env=0x0)
> at perl.c:1613
> #6 0x000000000041ce45 in main (argc=2, argv=0x7fffffffde88,
> env=0x7fffffffdea0) at perlmain.c:118

For me, with the ‘my $t : need_this;’ line deleted, this command:

$ PERL_DESTRUCT_LEVEL=1 ../perl.git-copy/Porting/bisect.pl
--target=miniperl -DDEBUGGING -Duseithreads -e '`$^X -Ilib ../foo`; warn
$?; die if ($?>>8) != 255'

points to this commit:

f12005599f648e675af22dfef1047191e260bc48 is the first bad commit
commit f12005599f648e675af22dfef1047191e260bc48
Author: Wolfram Humann <w.c.humann [at] arcor>
Date: Fri Aug 13 17:20:26 2010 -0700

make string-append on win32 100 times faster

When a string grows (e.g. gets appended to), perl calls sv_grow. When
sv_grow decides that the memory currently allocated to the string is
insufficient, it calls saferealloc. Depending on whether or not perl
was compiled with 'usemymalloc' this calls realloc in either perls
internal version or on the operating system. Perl requests from
realloc just the amount of memory required for the current
operation. With 'usemymalloc' this is not a problem because it rounds
up memory allocation to a certain geometric progression anyway. When
the operating system's realloc is called, this may or may not lead to
desaster, depending on how it's implemented. On win32 it does lead to
desaster: when I loop 1000 times and each time append 1000 chars to an
initial string size of 10 million, the memory grows from 10.000e6 to
10.001e6 to 10.002e6 and so on 1000 times till it ends at 11.000e6.

This is on darwin. I couldn’t reproduce in on dromedary, hence:

That took 1710 seconds

--

Father Chrysostomos

---
via perlbug: queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312

davem at iabyn

Apr 7, 2012, 2:47 PM

Post #7 of 16 (207 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Fri, Apr 06, 2012 at 05:44:56PM -0700, Father Chrysostomos via RT wrote:
> On Fri Apr 06 13:43:56 2012, perl [at] profvince wrote:
> > On 06/04/2012 22:27, James E Keenan via RT wrote:
> > > It appears there are two syntax errors here. If $t is a hash reference,
> > > then there should be a comma after {size} -- not a semicolon. And
> > > '(used}' probably should be '{used},'.
> > >
> > > Thank you very much.
> > > Jim Keenan
> > >
> > > ---
> > > via perlbug: queue: perl5 status: new
> > > https://rt.perl.org:443/rt3/Ticket/Display.html?id=112312
> > >
> >
> > perl shouldn't crash, regardless of whether the code is valid or not.
> >
> > I can confirm the segfault with a perl built with PERL_POISON defined
> > (otherwise my system's libc isn't sensitive enough to catch it). 5.12.4
> > doesn't crash, but 5.14.2, 5.15.3 and 5.15.6 do. Here's a stacktrace for
> > perl 5.14.2 :
>
> Can we make this a 5.16 blocker?

valgrind shows that the fault goes back as far as 5.10.0 and has been
present ever since; whether it happens to segfault is just down to
circumstance.

Given how long this bug has been present, I don't think it needs to be a
5.16 blocker.

--
Hofstadter's Law: It always takes longer than you expect, even when you
take into account Hofstadter's Law.

nick at ccl4

Apr 8, 2012, 3:31 AM

Post #8 of 16 (205 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Sat, Apr 07, 2012 at 10:47:44PM +0100, Dave Mitchell wrote:
> On Fri, Apr 06, 2012 at 05:44:56PM -0700, Father Chrysostomos via RT wrote:
> > On Fri Apr 06 13:43:56 2012, perl [at] profvince wrote:

> > > perl shouldn't crash, regardless of whether the code is valid or not.
> > >
> > > I can confirm the segfault with a perl built with PERL_POISON defined
> > > (otherwise my system's libc isn't sensitive enough to catch it). 5.12.4
> > > doesn't crash, but 5.14.2, 5.15.3 and 5.15.6 do. Here's a stacktrace for
> > > perl 5.14.2 :
> >
> > Can we make this a 5.16 blocker?
>
> valgrind shows that the fault goes back as far as 5.10.0 and has been
> present ever since; whether it happens to segfault is just down to
> circumstance.
>
> Given how long this bug has been present, I don't think it needs to be a
> 5.16 blocker.

I bisected with this:

$ cat ../112312.sh #!/bin/sh

valgrind --error-exitcode=1 ./perl -Ilib <<'EOT'
use strict;
use warnings;
sub meow (&);
my %h;
my $k;

meow {
my $t : need_this;
$t = {
size => $h{$k}{size};
used => $h{$k}(used}
};
};
EOT

ret=$?
test $ret -eq 255 && exit 0
exit $ret

and got to this commit:

HEAD is now at 9a51af3 Fix a typo in Dynaloader_pm.PL.
good - zero exit from ../112312.sh
0aded6e1de0ffebe70e2ec9f995c5ca8a55617d4 is the first bad commit
commit 0aded6e1de0ffebe70e2ec9f995c5ca8a55617d4
Author: Dave Mitchell <davem [at] fdisolutions>
Date: Thu Jan 18 02:14:48 2007 +0000

disable parser stack cleanup on reduce croak (too fragile)

p4raw-id: //depot/perl [at] 2986

:100644 100644 a9e569d9c9ccd42ad9241f0d6881f30607ac2c57 c8ee62ffc62dfcd4f5a7079f97775fa70562b6e8 M perly.c
bisect run success
That took 2216 seconds

IIRC this was the reversion of some work to deal with leaking ops, so I went
looking for whether it previously was a regression. I *think* this is the
earliest commit relating to OP leaking:

commit 0539ab63267d5a989c8b513c410c39b33c15aa25
Author: Dave Mitchell <davem [at] fdisolutions>
Date: Sat May 27 00:31:33 2006 +0000

stop OPs leaking in eval "syntax error"
When bison pops states during error recovery, any states holding
an OP would leak the OP. Create an extra YY table that tells us
which states are of type opval, and when popping one of those,
free the op.

p4raw-id: //depot/perl [at] 2831

so I built its parent, and for that valgrind shows no errors. So, sadly, I
think that the commit 0aded6e1de0ffebe is the immediate cause of this.

But, I'm suspecting, that the only *real* fix to all of this mess is to
garbage collect the OPs, in some fashion.

Nicholas Clark

davem at iabyn

Apr 8, 2012, 3:42 AM

Post #9 of 16 (207 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Sun, Apr 08, 2012 at 11:31:37AM +0100, Nicholas Clark wrote:
> But, I'm suspecting, that the only *real* fix to all of this mess is to
> garbage collect the OPs, in some fashion.

Ah yes, *that* quagmire.
Anyway, thanks for bisecting this.
It may be that my disabling of the experimental anti-leaking code just
didn't quite disable enough.

--
"Do not dabble in paradox, Edward, it puts you in danger of fortuitous wit."
-- Lady Croom, "Arcadia"

nick at ccl4

Apr 8, 2012, 4:05 AM

Post #10 of 16 (207 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Sun, Apr 08, 2012 at 11:42:06AM +0100, Dave Mitchell wrote:
> On Sun, Apr 08, 2012 at 11:31:37AM +0100, Nicholas Clark wrote:
> > But, I'm suspecting, that the only *real* fix to all of this mess is to
> > garbage collect the OPs, in some fashion.
>
> Ah yes, *that* quagmire.
> Anyway, thanks for bisecting this.

No problem. I'm waiting for the HP-UX box to build things.

I was also wondering if it would be simple enough to add a --valgrind option
to the bisect thingy to make this fall-off-a-log easy for anyone to do in
future (ie valgrind --error-exitcode=1 ./perl ...). *But* the use case here
was syntax checking, which that seems to be something we're going to need to
test again, and as one can see from the structure of the shell script, it's
not as simple as I'd hoped. A failure exit code from valgrind is a failure,
whereas a failure exit code passed through from the perl interpreter (because
valgrind found no errors) is a pass.

$ cat ../112312.sh
#!/bin/sh

valgrind --error-exitcode=1 ./perl -Ilib <<'EOT'
use strict;
use warnings;
sub meow (&);
my %h;
my $k;

meow {
my $t : need_this;
$t = {
size => $h{$k}{size};
used => $h{$k}(used}
};
};
EOT

ret=$?
test $ret -eq 255 && exit 0
exit $ret

So I'll do something else for a bit, to see if inspiration attacks.
(Or maybe lunch will attack first.)

Nicholas Clark

davem at iabyn

Apr 25, 2012, 3:37 AM

Post #11 of 16 (182 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Tue, Apr 24, 2012 at 02:01:45PM -0700, Father Chrysostomos via RT wrote:
> On Sun Apr 08 03:32:21 2012, nicholas wrote:
> > But, I'm suspecting, that the only *real* fix to all of this mess is
> > to
> > garbage collect the OPs, in some fashion.
>
> The simplest way might be to create something like the mortals’ stack,
> but for OPs. Or maybe a mortalop hash.
>
> Code that could croak can do the equivalent of SAVEFREEOP, and then
> delete the op from the mortalop stack when everything is safe.
>
> Would that be as fast as a tortoise, or slower?
>
> Or maybe a suggestion I had earlier: a variant of SAVEFREEOP that uses
> the savestack but returns a token (probably a stack offset) that can be
> used to disarm the item on the savestack and turn it into a no-op:
>
> I32 token = SAVEFREEOP_token(o);
> ... do something unsafe that might croak ...
> DISARM_SAVESTACK(token);
> op_free(o);

I think another suggestion that was mooted a while ago would be to
allocate OPs from a pool or slab, with a new pool/slab started each time
we start compiling a new sub, and the pool in some way marked as complete
at the end of compiling the sub. On croaking, all the OPs in the
unfinished pools are freed. That way most code doesn't need to be
modified.

--
"Procrastination grows to fill the available time"
-- Mitchell's corollary to Parkinson's Law

davem at iabyn

May 20, 2012, 1:33 AM

Post #12 of 16 (168 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Thu, May 17, 2012 at 10:02:39AM -0700, Father Chrysostomos via RT wrote:
> On Wed Apr 25 03:38:30 2012, davem wrote:
> > I think another suggestion that was mooted a while ago would be to
> > allocate OPs from a pool or slab, with a new pool/slab started each time
> > we start compiling a new sub, and the pool in some way marked as complete
> > at the end of compiling the sub. On croaking, all the OPs in the
> > unfinished pools are freed. That way most code doesn't need to be
> > modified.
>
> What exactly is that code at the top of op.c that is compiled only when
> PL_OP_SLAB_ALLOC is defined?

It's Nick Ing-Simmons's "Experimental" slab allocator for op from 1999.
Its never normally used, apart from, apparently, when PERL_IMPLICIT_SYS is
defined.

I suspect it would need heavy reworking to make it into a 'one pool per CV
and throw the whole thing away on error' system.

commit b7dc083c47d05133e90d62e8b587c747dab89267
Author: Nick Ing-Simmons <nik [at] tiuk>
AuthorDate: Fri May 14 21:04:22 1999 +0000
Commit: Nick Ing-Simmons <nik [at] tiuk>
CommitDate: Fri May 14 21:04:22 1999 +0000

Experimental "slab" allocator for ops.
To try it -DPL_OP_SLAB_ALLOC for op.c
This is for proof of concept only, it leaks memory
(ops are not free'd) so don't use in embedded apps.
If this minimalist version does not show performance
gain then whole idea is worthless.
Nick see's approx 12% speed up vs perlmalloc running
perl -Ilib -MCPAN -e ''
Solaris2.6, gcc-2.8.1 but numbers are not repeatable.

--
Nothing ventured, nothing lost.

rurban at x-ray

Jun 10, 2012, 1:23 PM

Post #13 of 16 (166 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Sun, Apr 8, 2012 at 6:05 AM, Nicholas Clark <nick [at] ccl4> wrote:
> On Sun, Apr 08, 2012 at 11:42:06AM +0100, Dave Mitchell wrote:
>> On Sun, Apr 08, 2012 at 11:31:37AM +0100, Nicholas Clark wrote:
>> > But, I'm suspecting, that the only *real* fix to all of this mess is to
>> > garbage collect the OPs, in some fashion.
>>
>> Ah yes, *that* quagmire.
>> Anyway, thanks for bisecting this.
>
> No problem. I'm waiting for the HP-UX box to build things.
>
> I was also wondering if it would be simple enough to add a --valgrind option
> to the bisect thingy to make this fall-off-a-log easy for anyone to do in
> future (ie valgrind --error-exitcode=1 ./perl ...).

I suggest to rather use clang -faddress-sanitizer as it is much
faster, does not need such a hack and detects many more such errors
than valgrind.

Similar errors are in various CPAN modules also.
--
Reini Urban
http://cpanel.net/ � http://www.perl-compiler.org/

davem at iabyn

Jun 25, 2012, 4:56 AM

Post #14 of 16 (163 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Fri, Jun 22, 2012 at 06:31:52PM -0700, Father Chrysostomos via RT wrote:
> On Wed Apr 25 03:38:30 2012, davem wrote:
> > I think another suggestion that was mooted a while ago would be to
> > allocate OPs from a pool or slab, with a new pool/slab started each time
> > we start compiling a new sub, and the pool in some way marked as complete
> > at the end of compiling the sub. On croaking, all the OPs in the
> > unfinished pools are freed. That way most code doesn't need to be
> > modified.
>
> You mean something like this attachment?

yes, thanks :-)

From a cursory read of the commit message, it looks good. The only thing
that stood out for me was:

> I tried eliminating reference counts altogether, by having all ops
> implicitly attached to PL_compcv when allocated and freed when the CV
> is freed. That also allowed op_free to skip FreeOp altogether, free-
> ing ops faster. But that doesn’t work in those cases where ops need
> to survive beyond their CVs; e.g., re-evals.

IIRC, all OPs allocated for /(?{})/ code blocks are now firmly owned by a
CV:

1 for literal matches, /(?{})/, they are in the CV containing the match;
2 for literal qr, qr/(?{})/, they are stored in an anon CV which is
attached to the regex, and cloned each time the qr// is run;
3 for run-time code, the pattern is wrapped in a qr// and reparsed,
so (2) applies.
4 when a qr// is interpolated into another pattern, e.g
$r = qr/(?{})/; /a-$r/, then the new regex contains both pointers
to the ops within the (?{}), but also a pointer to the CV those ops
are embedded in: so they won't outlive the CV.

--
More than any other time in history, mankind faces a crossroads. One path
leads to despair and utter hopelessness. The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
-- Woody Allen

davem at iabyn

Jun 25, 2012, 9:30 AM

Post #15 of 16 (162 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Mon, Jun 25, 2012 at 08:20:27AM -0700, Father Chrysostomos via RT wrote:
> The ops may all be attached to CVs, but I know that sometimes the op
> that the CV is finally attached to is not the same one that was
> PL_compcv when the op was created.
>
> Stepping through the debugger while working on it, I found out this:
>
> The PMFUNC branch of the term rule in perly.y calls start_subparse.
> Then a const op is created in toke.c to hold the pattern (I don’t
> remember exactly where), and then op.c:pmruntime is called, hence this hunk:
>
> @@ -4373,6 +4579,10 @@ Perl_pmruntime(pTHX_ OP *o, OP *expr, bool isreg,
> I32 floor)
> * confident that nothing used that CV's pad while the
> * regex was parsed */
> assert(AvFILLp(PL_comppad) == 0); /* just @_ */
> +#ifndef PL_OP_SLAB_ALLOC
> + /* But we know that one op is using this CV's slab. */
> + cv_forget_slab(PL_compcv);
> +#endif
> LEAVE_SCOPE(floor);
> pm->op_pmflags &= ~PMf_HAS_CV;
> }

I'm confused. My understand of that code path is that toke.c creates a
PMOP (using the "main" PL_compcv); *then* start_subparse() is called
(changing PL_compcv), *then* pmruntime() runs the "whoops, guessed wrong"
code and frees the inner PL_compcv. I don't see any ops being created
between the start_subparse and the pmruntime ???

--
Never do today what you can put off till tomorrow.

davem at iabyn

Jun 25, 2012, 2:40 PM

Post #16 of 16 (162 views)
Permalink

Re: [perl #112312] perl5 version 5.14.2 coredumps during perl -c [In reply to]

On Mon, Jun 25, 2012 at 11:09:50AM -0700, Father Chrysostomos via RT wrote:
> Breakpoint 1, Perl_start_subparse (is_format=0, flags=128) at toke.c:10759
> 10759 const I32 oldsavestack_ix = PL_savestack_ix;
> (gdb) up

> Breakpoint 3, Perl_Slab_Alloc (sz=24) at op.c:331
> 331 if (!PL_compcv || CvROOT(PL_compcv)
> (gdb) bt
> #0 Perl_Slab_Alloc (sz=24) at op.c:331
> #1 0x0001a167 in Perl_newSVOP (type=5, flags=0, sv=0x8222f0) at op.c:4847
> #2 0x000560d5 in S_scan_const (start=0x305840 "(?#(?{)") at toke.c:3578

Ah, *that* const op ;-)
Somehow I missed triggering an op alloc breakpoint when I tried it
earlier.

In which case, as regards my code, yuck!
That "we guessed we had a code block but it turns out we didn't" bit of
code was always a bit of hack, and now that I realise it leaves an op
allocated in the wrong CV, I like it even less.

I'm tempted to eliminate it altogether. Would doing this enable you to
simplify the slab code?

--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads