[perl #56712] [BUG] --optimize causes perl6 to segfault during make
Jason Switzer
# Please include the string: [perl #56712]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56712 >
When trying to use the --optimize flag, building perl6 causes parrot to
segfault. Attached is the Configure.pl script output. Below is a backtrace
by manually performing the make step from gdb. You'll notice the second run
performs the same operation with the -G option to disable memory management.
Seperate executions have generated slightly different backtraces (likely due
to signal timings). This is not caused by the --inline Configure.pl option.
s1n@citadel ~/Projects/parrot $ gdb ./parrot
GNU gdb 6.8
Copyright (C) 2008 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"...
(gdb) r /home/s1n/Projects/parrot/compilers/nqp/nqp.pbc
--output=languages/perl6/src/gen_actions.pir --encoding=fixed_8 --target=pir
languages/perl6/src/parser/actions.pm
Starting program: /home/s1n/Projects/parrot/parrot
/home/s1n/Projects/parrot/compilers/nqp/nqp.pbc
--output=languages/perl6/src/gen_actions.pir --encoding=fixed_8 --target=pir
languages/perl6/src/parser/actions.pm
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0000000000000190
[New Thread 0x2af629b5bd00 (LWP 32162)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2af629b5bd00 (LWP 32162)]
0x00002af623ea64de in Parrot_ResizablePMCArray_set_pmc_keyed_int
(interp=0x60a610, pmc=0x1144d20,
key=6, src=0x1144ce8) at ./src/pmc/resizablepmcarray.pmc:245
245 data[key] = src;
(gdb) bt
#0 0x00002af623ea64de in Parrot_ResizablePMCArray_set_pmc_keyed_int
(interp=0x60a610,
pmc=0x1144d20, key=6, src=0x1144ce8) at
./src/pmc/resizablepmcarray.pmc:245
#1 0x00002af623e7d30a in Parrot_Class_instantiate (interp=0x60a610,
pmc=0x9d9370, init=0x65df50)
at ./src/pmc/class.pmc:337
#2 0x00002af623d3f4b0 in Parrot_new_p_s (cur_opcode=0x2aaaaac31640,
interp=0x60a610)
at src/ops/pmc.ops:90
#3 0x00002af623dbbc9c in runops_slow_core (interp=0x60a610,
pc=0x2aaaaac31640)
at src/runops_cores.c:221
#4 0x00002af623d8cbe1 in runops_int (interp=0x60a610, offset=3280) at
src/interpreter.c:918
#5 0x00002af623d8d47d in runops (interp=0x60a610, offs=<value optimized
out>) at src/inter_run.c:106
#6 0x00002af623d8d6d0 in runops_args (interp=0x60a610, sub=<value optimized
out>,
obj=<value optimized out>, meth_unused=<value optimized out>,
sig=0x2af623ee10c4 "vP",
ap=0x7fff87116c40) at src/inter_run.c:232
#7 0x00002af623d8de2b in Parrot_runops_fromc_args (interp=0x60a610,
sub=0x1144d20,
sig=0x4 <Address 0x4 out of bounds>) at src/inter_run.c:301
#8 0x00002af623ec69e2 in imcc_run (interp=0x60a610, sourcefile=<value
optimized out>, argc=5,
argv=0x7fff87116e90) at compilers/imcc/main.c:782
#9 0x0000000000400c42 in main (argc=5, argv=0x7fff87116e90) at
src/main.c:61
(gdb) r -G /home/s1n/Projects/parrot/compilers/nqp/nqp.pbc
--output=languages/perl6/src/gen_actions.pir --encoding=fixed_8 --target=pir
languages/perl6/src/parser/actions.pm
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/s1n/Projects/parrot/parrot -G
/home/s1n/Projects/parrot/compilers/nqp/nqp.pbc
--output=languages/perl6/src/gen_actions.pir --encoding=fixed_8 --target=pir
languages/perl6/src/parser/actions.pm
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0000000000000190
Program exited normally.
Chromatic
> When trying to use the --optimize flag, building perl6 causes parrot to
> segfault. Attached is the Configure.pl script output. Below is a backtrace
> by manually performing the make step from gdb. You'll notice the second run
> performs the same operation with the -G option to disable memory
> management. Seperate executions have generated slightly different
> backtraces (likely due to signal timings). This is not caused by the
> --inline Configure.pl option.
Can you still reproduce this? I've seen a few weird 64-bit problems with GC
in the past couple of months. Narrowing this down would be very handy.
-- c
Nicholas Clark
> On Tue, 22 Sep 2009, Will Coleda via RT wrote:
>
> > On Tue Jul 08 20:56:02 2008, s1n wrote:
> > > When trying to use the --optimize flag, building perl6 causes parrot
> > to
> > > segfault. Attached is the Configure.pl script output.
> >
> > s1n - this original report is over a year old; there have been a lot of
> > changes to both parrot and rakudo in that time; we've also just
> > committed something that should cause the optimized build to at least
> > fail more cleanly if there's a problem (which we can then more easily
> > identify and resolve.)
>
> Actually, all those ASSERT_ARGS checks aren't used in the --optimize build
> anyway. Applying the following patch should enable them, assuming that's
> what is actually intended.
I don't think that it's absolutely necessary.
The intent (at least in Perl 5 land) was to have the non-optimised build spot
all the places where the non-NULL annotations were wrong, on the assumption
that the code paths would be identical in the optimised and non-optimised
builds.
Of course, my opinion is that
a) the compiler should be capable of doing this
b) the compiler should provide analogous annotations for variables and struct
members. Right now, it's like being able to declare function parameters
as const pointers, but not being able to have const pointers as variables
or in structs, and any assignments to pointers silently casting away const.
Nicholas Clark
Andy Dougherty
> On Tue Jul 08 20:56:02 2008, s1n wrote:
> > When trying to use the --optimize flag, building perl6 causes parrot
> to
> > segfault. Attached is the Configure.pl script output.
> <SNIP>
>
> s1n - this original report is over a year old; there have been a lot of
> changes to both parrot and rakudo in that time; we've also just
> committed something that should cause the optimized build to at least
> fail more cleanly if there's a problem (which we can then more easily
> identify and resolve.)
Actually, all those ASSERT_ARGS checks aren't used in the --optimize build
anyway. Applying the following patch should enable them, assuming that's
what is actually intended.
--- /parrot-svn/config/init/optimize.pm 2009-09-21 08:55:56.000000000 -0400
+++ parrot-andy/config/init/optimize.pm 2009-09-22 13:35:52.216068004 -0400
@@ -46,7 +46,7 @@
# disable debug flags
$conf->data->set( cc_debug => '' );
- $conf->data->add( ' ', ccflags => "-DDISABLE_GC_DEBUG=1 -DNDEBUG" );
+ $conf->data->add( ' ', ccflags => "-DDISABLE_GC_DEBUG=1" );
if ( $optimize eq "1" ) {
# use perl5's value
However, in principle, the various __nonnull__ attributes mean that gcc is
still free to optimize away at least some of the ASSERT checks.
--
Andy Dougherty doug...@lafayette.edu
Andy Dougherty
> On Tue, Sep 22, 2009 at 02:22:17PM -0400, Andy Dougherty wrote:
> > On Tue, 22 Sep 2009, Will Coleda via RT wrote:
> >
> > > On Tue Jul 08 20:56:02 2008, s1n wrote:
> > > > When trying to use the --optimize flag, building perl6 causes parrot
> > > to
> > > > segfault. Attached is the Configure.pl script output.
> > > <SNIP>
> > >
> > > s1n - this original report is over a year old; there have been a lot of
> > > changes to both parrot and rakudo in that time; we've also just
> > > committed something that should cause the optimized build to at least
> > > fail more cleanly if there's a problem (which we can then more easily
> > > identify and resolve.)
> >
> > Actually, all those ASSERT_ARGS checks aren't used in the --optimize build
> > anyway. Applying the following patch should enable them, assuming that's
> > what is actually intended.
>
> I don't think that it's absolutely necessary.
I would tend to agree, but Coke seemed to be implying that the intent was
otherwise.
> The intent (at least in Perl 5 land) was to have the non-optimised build
> spot all the places where the non-NULL annotations were wrong, on the
> assumption that the code paths would be identical in the optimised and
> non-optimised builds.
(One of the strange things about this report is that the failure only
happens with --optimize. And not just this report -- this has been an
issue on and off for years. But that probably doesn't really have
anything to do with ASSERT_ARGS.)
More generally, whatever the default setting, it might be nice to have a
way to change it. I could easily imagine
perl Configure.pl --optimize=-O --debugging=1
turning on the optimizer while still enabling all the -DNDEBUG checks, and
perl Configure.pl --optimize=-O --debugging=0
turning on the optimizer and leaving out all the -DNDEBUG checks.
Right now, that --optimize unconditionally leaves out the -DNDEBUG checks,
and the -debugging ends up doing nothing useful at all in those two
cases.
--
Andy Dougherty doug...@lafayette.edu
Will Coleda
> On Tue, 22 Sep 2009, Nicholas Clark wrote:
>
>> On Tue, Sep 22, 2009 at 02:22:17PM -0400, Andy Dougherty wrote:
>> > On Tue, 22 Sep 2009, Will Coleda via RT wrote:
>> >
>> > > On Tue Jul 08 20:56:02 2008, s1n wrote:
>> > > > When trying to use the --optimize flag, building perl6 causes parrot
>> > > to
>> > > > segfault. Attached is the Configure.pl script output.
>> > > <SNIP>
>> > >
>> > > s1n - this original report is over a year old; there have been a lot of
>> > > changes to both parrot and rakudo in that time; we've also just
>> > > committed something that should cause the optimized build to at least
>> > > fail more cleanly if there's a problem (which we can then more easily
>> > > identify and resolve.)
>> >
>> > Actually, all those ASSERT_ARGS checks aren't used in the --optimize build
>> > anyway. Applying the following patch should enable them, assuming that's
>> > what is actually intended.
>>
>> I don't think that it's absolutely necessary.
>
> I would tend to agree, but Coke seemed to be implying that the intent was
> otherwise.
Apologies. I think you and Nick are right on this.
>> The intent (at least in Perl 5 land) was to have the non-optimised build
>> spot all the places where the non-NULL annotations were wrong, on the
>> assumption that the code paths would be identical in the optimised and
>> non-optimised builds.
>
> (One of the strange things about this report is that the failure only
> happens with --optimize. And not just this report -- this has been an
> issue on and off for years. But that probably doesn't really have
> anything to do with ASSERT_ARGS.)
>
> More generally, whatever the default setting, it might be nice to have a
> way to change it. I could easily imagine
>
> perl Configure.pl --optimize=-O --debugging=1
>
> turning on the optimizer while still enabling all the -DNDEBUG checks, and
>
> perl Configure.pl --optimize=-O --debugging=0
>
> turning on the optimizer and leaving out all the -DNDEBUG checks.
>
> Right now, that --optimize unconditionally leaves out the -DNDEBUG checks,
> and the -debugging ends up doing nothing useful at all in those two
> cases.
>
> --
> Andy Dougherty doug...@lafayette.edu
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
I regularly do 'perl Configure.pl --optimize --ccflags=-g' , which
probably isn't quite the same thing but might be useful.
--
Will "Coke" Coleda