Mailing List Archive

[perl #78398] eval STRING compilation failure breaks overloading
# New Ticket Created by
# Please include the string: [perl #78398]
# in the subject line of all future correspondence about this issue.
# <URL: >

This is a bug report for perl from,
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/, 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
[perl #78398] eval STRING compilation failure breaks overloading [ In reply to ]
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?
[perl #78398] eval STRING compilation failure breaks overloading [ In reply to ]
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
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 <>
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.