Tied methods break when combined with eval() of failing compile-time code

[p5pRT]

Migrated from rt.perl.org#23810 (status was 'resolved')

Searchable as RT23810$

[p5pRT]

From jason@gossamer-threads.com

The following example demonstrates the problem quite well​:

perl -e '
package Breaks;
use Tie​::Hash;
@​ISA = qw(Tie​::StdHash);
sub FETCH { eval "BEGIN { some bad code }"; return 1 }

package main;
my %foo;
my $f = tie %foo, "Breaks";

print "Calling FETCH explicitly ...\n";
$f->FETCH("bar");

print "\tdone.\nCalling FETCH implicitly ...\n";
$foo{bar};

print "\tdone.\n"
'

The output from this is​:

Calling FETCH explicitly ...
  done.
Calling FETCH implicitly ...
Can't return outside a subroutine at -e line 5.

In more complex situations, this causes Perl to segfault (at once point
I also got a "panic​: pp_iter"). I've also tested it with other tied
methods and types - it seems that _any_ tied method (i.e. FETCH, STORE,
KEYS, etc.) for _any_ tied object type (I tested with tied hashes,
arrays, and scalars) that does this sort of eval causes the error. It
doesn't have to be an explicit BEGIN block either - 'use Foo' in the
eval (where Foo.pm doesn't exist) causes this to occur as well - which
is how I originally discovered the bug.

Just for fun, I threw the implicit FETCH inside a subroutine (sub main)
and called it - the result was that the return value of the FETCH is
returned to the point where I called main, ignoring any remaining code
in sub main.

I figured out a rather nasty workaround, by wrapping the eval around
another eval, something like​:

eval q{my $ret = eval "BEGIN { some bad code }"; die "$@​\n" if $@​; $ret};

I'm curious why the extra eval makes this work - admittedly it was
something of a shot in the dark to fixing my specific problem. I'll
have to live with this solution, as the code I'm working on needs to
work in older Perl's, but it obviously isn't a very nice solution.

Perl Info

Flags:
    category=core
    severity=high

Site configuration information for perl v5.8.1:

Configured by jagerman at Mon Aug 25 13:49:17 PDT 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.4.21-pfeifer-r1_pre4, archname=i686-linux-thread-multi
    uname='linux cytherea.office.gossamer-threads.com 2.4.21-pfeifer-r1_pre4 #1 wed jul 23 21:38:48 pdt 2003 i686 amd athlon(tm) authenticamd gnulinux '
    config_args='-des -Darchname=i686-linux-thread -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dlocincpth=  -Doptimize=-march=athlon-xp -O3 -mmmx -msse -m3dnow -mfpmath=sse -pipe -fomit-frame-pointer -fforce-addr -funroll-loops -frerun-loop-opt -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman3ext=3pm -Dcf_by=Gentoo -Ud_csh -Dusethreads -Di_gdbm -Di_db -Di_ndbm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-march=athlon-xp -O3 -mmmx -msse -m3dnow -mfpmath=sse -pipe -fomit-frame-pointer -fforce-addr -funroll-loops -frerun-loop-opt',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing'
    ccversion='', gccversion='3.3.1  (Gentoo Linux 3.3.1, propolice)', 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='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    RC4


@INC for perl v5.8.1:
    /etc/perl
    /usr/lib/perl5/site_perl/5.8.1/i686-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.1
    /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.1/i686-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.1
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.1/i686-linux-thread-multi
    /usr/lib/perl5/5.8.1
    /usr/local/lib/site_perl
    /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0
    .


Environment for perl v5.8.1:
    HOME=/home/jagerman
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin/wrappers:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3:/opt/ati/bin:/opt/Acrobat5:/opt/f-prot:/usr/X11R6/bin:/opt/sun-j2sdk-1.4.1/bin:/opt/sun-j2sdk-1.4.1/jre/bin:/usr/qt/3/bin:/usr/games/bin:/opt/quake3:/opt/vmware/bin:/usr/X11R6/bin:/home/jagerman/bin:/opt/perl/perl-5.00404/bin:/opt/perl/perl-5.005/bin:/opt/perl/perl-5.00503/bin:/opt/perl/perl-5.6.1/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash


-- 
-- Jason Rhinelander
-- Gossamer Threads, Inc.

[p5pRT]

From @iabyn

On Mon, Sep 15, 2003 at 09​:18​:13AM -0000, Jason Rhinelander wrote​:

The following example demonstrates the problem quite well​:

perl -e '
package Breaks;
use Tie​::Hash;
@​ISA = qw(Tie​::StdHash);
sub FETCH { eval "BEGIN { some bad code }"; return 1 }

package main;
my %foo;
my $f = tie %foo, "Breaks";

print "Calling FETCH explicitly ...\n";
$f->FETCH("bar");

print "\tdone.\nCalling FETCH implicitly ...\n";
$foo{bar};

print "\tdone.\n"
'

The output from this is​:

Calling FETCH explicitly ...
done.
Calling FETCH implicitly ...
Can't return outside a subroutine at -e line 5.

Perl is incorrectly popping too much context off the stack in the implicit
case.

Executing similar code (where I replaced the BEGIN {..} with BEGIN {die },
I found the following stack state immediately before and after pp_die() is
executed​:

---

implicit call

---

STACK 0​: MAIN
  CX 0​: BLOCK => HV() PVIV("bar")
  retop=(null)
STACK 1​: MAGIC
  CX 0​: SUB =>
  retop=nextstate
  CX 1​: EVAL => * CV(BEGIN)
  retop=(null)
  CX 2​: EVAL =>
  retop=(null)
  CX 3​: SUB => *

((eval 2)​:1) die

STACK 0​: MAIN
  CX 0​: BLOCK => HV() PVIV("bar")
  retop=(null)

---

explicit call

---

STACK 0​: MAIN
  CX 0​: BLOCK =>
  retop=nextstate
  CX 1​: SUB =>
  retop=nextstate
  CX 2​: EVAL => * CV(BEGIN)
  retop=(null)
  CX 3​: EVAL =>
  retop=(null)
  CX 4​: SUB => *

((eval 1)​:1) die

STACK 0​: MAIN
  CX 0​: BLOCK =>
  retop=nextstate
  CX 1​: SUB =>

(Note that in the implicit case, there are two context stacks, due to
the tied call).
The explicit case correctly pops off the eval stuff, leaving you in the
context that's executing the FETCH sub. The implicit case manages to lose
the sub context too.

tracing the code shows that die_where correctly pops the EVAL/EVAL/SUB,
then vdie() does a JMPENV_JUMP(3), which pops the C stack back to the
outermost execution spot in perl_run(), which then does
POPSTACK_TO(PL_mainstack), which I guess screws things up when threre's
more than one context stack.

At this point I give up, since the mechanisms for longjmping in Perl for
exception handling is way beyond this particular Bear of Little Brain. In
this matter, longjmping can be considered similar to the
Schleswig-Holstein question, which - in the words of Lord Palmerston - "only
three persons understood [...]​: one is dead, one went mad and I have
forgotten". Now which one of those three applies to Sarathy, I wonder? ;-)

Dave.

--
My get-up-and-go just got up and went.

[p5pRT]

From s0710509@u.tsukuba.ac.jp

This is a bug report for perl from s0710509@​unix01.u.tsukuba.ac.jp,
generated with the help of perlbug 1.36 running under perl 5.10.1.

---

eval "use $module" in Perl_call_sv() without G_EVAL could cause segmentation faults on some perls. With G_EVAL, it doesn't occur.

gdb(1) suggests that segv occurs in setjmp(3), but I don't know its details.

See the following code​:
#!perl -w
use strict;
use Test​::More tests => 3;
{
  package T;
  use Tie​::Hash();
  use base qw(Tie​::StdHash);

  # FETCH() is called via Perl_call_sv()
  sub FETCH{
  my($self, $key) = @​_;
  # XXX​: "require $key" is okey
  eval "use $key(); 1";
  }
}
tie my(%t), 'T';
ok $t{Cwd}, 'existing module';
ok!$t{'No​::Such​::Module'}, 'non-existing module';
ok $t{strict}, 'existing module';
__END__

---

---

Flags​:
  category=core
  severity=high

---

This perlbug was built using Perl 5.10.0 - Mon Jun 29 11​:42​:33 JST 2009
It is being executed now by Perl 5.10.1 - Wed Aug 26 15​:19​:00 JST 2009.

Site configuration information for perl 5.10.1​:

Configured by s0710509 at Wed Aug 26 15​:19​:00 JST 2009.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration​:
 
  Platform​:
  osname=linux, osvers=2.6.18-92.el5pae, archname=i686-linux
  uname='linux unix01.u.tsukuba.ac.jp 2.6.18-92.el5pae #1 smp tue apr 29 13​:31​:02 edt 2008 i686 i686 i386 gnulinux '
  config_args='-des -Doptimize=-O3 -Dprefix=~/sperl -Accflags=-Wall -Wextra -pipe -Dinc_version_list=none -Dcc=gcc43'
  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
  Compiler​:
  cc='gcc43', ccflags ='-Wall -Wextra -pipe -fno-strict-aliasing -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O3',
  cppflags='-Wall -Wextra -pipe -fno-strict-aliasing -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.3.2 20081007 (Red Hat 4.3.2-7)', 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='gcc43', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib
  libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.5'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O3 -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 

---

@​INC for perl 5.10.1​:
  /home/s0710509/sperl/lib/5.10.1/i686-linux
  /home/s0710509/sperl/lib/5.10.1
  /home/s0710509/sperl/lib/site_perl/5.10.1/i686-linux
  /home/s0710509/sperl/lib/site_perl/5.10.1
  .

---

Environment for perl 5.10.1​:
  HOME=/home/s0710509
  LANG=C
  LANGUAGE (unset)
  LD_LIBRARY_PATH=/usr/lib​:/usr/local/lib
  LOGDIR (unset)
  PATH=/home/s0710509/bin​:/home/s0710509/perl/5.10.0/bin​:/home/s0710509/mperl/bin​:/home/s0710509/sperl/bin​:/home/s0710509/bleadperl/bin​:/home/s0710509/oldperl/bin​:/home/s0710509/ancientperl/bin​:/usr/kerberos/bin​:/usr/local/phylip-3.68​:/usr/java/jdk1.6.0_12/bin​:/usr/java/jre1.6.0_11/bin​:/usr/local/eclipse​:/usr/local/bin​:/bin​:/usr/bin​:/usr/local/RealPlayer
  PERL_BADLANG (unset)
  SHELL=/bin/bash

[p5pRT]

From jarich@perltraining.com.au

G'day,

Thank you for spotting this bug, this is indeed an issue. We'll do what
we can to work out some way of fixing it; Perl should not seg-fault.

All the best,

  Jacinta

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @iabyn

Now fixed by commit 27e9045
in branch davem/post-5.12, which should be merged back into blead
once 5.12 has been released, and thus appear in 5.13 onwards.

[p5pRT]

@iabyn - Status changed from 'open' to 'resolved'

[p5pRT]

From @cpansprout

This was fixed by 27e9045.

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'