# New Ticket Created by hdp@glaive.weftsoar.net
# Please include the string: [perl #78398]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=78398 >

This is a bug report for perl from hdp@glaive.weftsoar.net,
generated with the help of perlbug 1.39 running under perl 5.10.1.

[Please describe your issue here]

Using eval STRING inside an overload method causes stack corruption when STRING
has compile-time errors.

Commenting out the eval makes it work; or changing it to just eval "require Foo::Bar"
putting it inside { local $@; eval ... } makes it abort:
perl: pp_ctl.c:2073: Perl_pp_leaveloop: Assertion `(((cx)->cx_u.cx_subst.sbu_type & 0xC) == 0x4)' fail.
perl 5.10.1 and 5.8.9 segfault here instead of aborting.
Any compile-time error works, like "BEGIN { !@#!@# }" or "use Foo::Bar"

use overload (q{""} => 'str');
sub new { bless {} }
sub str {
eval "BEGIN { require Foo::Bar }";
return 1;

main->new() . "";

[Please do not change anything below this line]
Site configuration information for perl 5.10.1:

Configured by hdp at Sun Apr 11 07:47:29 EDT 2010.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:

osname=linux, osvers=, archname=i686-linux
uname='linux glaive #1 smp mon oct 26 18:17:01 utc 2009 i686 gnulinux '
config_args='-de -Dprefix=/home/hdp/perl5/perlbrew/perls/perl-5.10.1'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.3.3', 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 =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/lib64
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.9.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:

@INC for perl 5.10.1:

Environment for perl 5.10.1:
LANGUAGE (unset)
LOGDIR (unset)
PERL_CPANM_OPT=--prompt --skip-installed --mirror http://cpan.cpantesters.org

Search Discussions

  • Florian Ragwitz via RT at Oct 16, 2010 at 9:08 am
    For me, it fails slightly differently.

    "Can't return outside a subroutine at" from the return in the overloaded

    This is probably the same problem you're seeing, but with a different
    effect. It might indicate that the exception is unwinding a little too far?

    Also, I can't produce this on blead. I can't see any recent changes to
    amagic_call and friends that would fix anything like that. Is it
    possible that the general exception sanity fixes took care of this as well?

    A bisect run, anyone?
  • Florian Ragwitz via RT at Oct 16, 2010 at 12:34 pm
    Apparently this is already fixed in 5.13.0. Here's the bisect result.

    git bisect start
    # bad: [a4ef29484100fcd961129071b2ca69064250b195] Add 5.13.0 to perlhist
    git bisect bad a4ef29484100fcd961129071b2ca69064250b195
    # good: [6d52c880307229a35c23215c596700e716bd7c32] Removing the RC
    marker from patchlevel.h
    git bisect good 6d52c880307229a35c23215c596700e716bd7c32
    # bad: [d1515be42a17e7bb3fa584aea980f54524603f34] mark two magic.t tests
    as TODO
    git bisect bad d1515be42a17e7bb3fa584aea980f54524603f34
    # bad: [1bb125e2afe6197deaf55852a3f8a9c52736bfdc] Note how to deal with
    broken dbm.h on OpenSUSE
    git bisect bad 1bb125e2afe6197deaf55852a3f8a9c52736bfdc
    # bad: [11035fcf28d4d5fe35c7f6719dbd07b704a8f266] remove 'enable taint
    if modify gid/uid' feature
    git bisect bad 11035fcf28d4d5fe35c7f6719dbd07b704a8f266
    # good: [099be4f1d597471eb719c9a344b7c1b55e11ba24] PL_defoutgv isn't
    always a GV.
    git bisect good 099be4f1d597471eb719c9a344b7c1b55e11ba24
    # bad: [27e904532594b7fb224bdf9a05bf3b5336b8a39e] fix RT 23810: eval and
    tied methods
    git bisect bad 27e904532594b7fb224bdf9a05bf3b5336b8a39e
    # good: [91e35ba127b7082418836f7f9f428e4d2f9b5745] more mods to -Dl
    debugging output
    git bisect good 91e35ba127b7082418836f7f9f428e4d2f9b5745

    27e904532594b7fb224bdf9a05bf3b5336b8a39e is the first bad commit
    commit 27e904532594b7fb224bdf9a05bf3b5336b8a39e
    Author: David Mitchell <davem@iabyn.com>
    Date: Thu Apr 8 13:16:56 2010 +0100

    fix RT 23810: eval and tied methods

    Something like the following ended up corrupted:
    sub FETCH { eval 'BEGIN{syntax err}' }
    The croak on error popped back the context stack etc to the EVAL
    pushed by
    entereval, but the corresponding JUMPENV_PUSH(3) unwound all the way
    to the
    outer perl_run, losing all the mg_get() related parts of the C stack.

    It turns out that the run-time parts of pp_entereval were protected with
    a new JUMPENV level, but the compile-time parts weren't. Add this.

    :100644 100644 80c7b221d7e967a6f3380d70917bd73700b16852
    bbb2d1587cb197977c996ecfe8abddf4f9aa3631 M pp_ctl.c
    :040000 040000 7fa8480b6084b533c3eaddbbbd6834e2551f8a4e
    f2ec8022695df42cff76ab78c117bd44d1fb626c M t

    So I'm closing this. Tests for this particular issue in combination with
    overload might be a good thing.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
postedOct 15, '10 at 2:54p
activeOct 16, '10 at 12:34p

1 user in discussion

Florian Ragwitz via RT: 3 posts



site design / logo © 2022 Grokbase