develooper Front page | perl.perl5.porters | Postings from April 2013

[perl #117607] (regression?) v5.17.6+ segfaulting on simple (buggy) code

Tony Cook via RT
April 22, 2013 01:29
[perl #117607] (regression?) v5.17.6+ segfaulting on simple (buggy) code
Message ID:
I bisected this with a debugging perl, and found:

bad - non-zero exit from ./perl -Ilib -e eval q[ use strict; $foo; sub {
\&CORE::lc } ];
a73ef99b394ac4c717d671b78792af7d844bbee1 is the first bad commit
commit a73ef99b394ac4c717d671b78792af7d844bbee1
Author: Father Chrysostomos <>
Date:   Wed Jun 20 13:45:43 2012 -0700

    [perl #113712] Don’t create stubs after errors

    perl5.002beta3 (c07a80fdfe) stopped bodies of subrou-
    tines from being defined after compilation errors, as in
    eval "@a =~ s///; sub { die }".

    But, instead of making the sub declaration not happen at all, it ended
    up leaving a stub.

    For a full sub declaration (body and all) to create a stub just
    seems wrong.

    Likewise, it would be weird if a stub declaration
    after a compilation error created a stub, because then
    eval "@a =~ s///; sub foo; sub bar { }" would create foo but not bar.

    Similarly, a compilation error will cause ‘sub foo {}’ no suppress
    ‘used once’ warnings; but a lexing error won’t.

    This commit fixes all this, making things consistent:  If there is a
    compilation, parsing or lexing error, any kind of sub declaration that
    follows is ignored.

:100644 100644 69bd2a4df8cc2eae325ed03e408b0fcc260be241
5756eeb302b761276050e88da216f754323e67e6 M      op.c
:040000 040000 ede63525624312bffafa5d226f9af4eb770e950c
d1ae239eaa8cb406eb2146e804434551909fc0cd M      t
bisect run success
That took 1639 seconds

via perlbug:  queue: perl5 status: open Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About