nested eval/sub segfaults

[p5pRT]

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

Searchable as RT9728$

[p5pRT]

From root@schmorp.de

Created by root@cerebro.laendle

The following program segfaults with perl-devel and 5.6.1, but not with
5.005_03​:

  $eval = eval 'sub { eval "sub { %S }" }';
  $eval->({});

here is a backtrace​:
 
  #0 Perl_av_fetch (av=0x13, key=0, lval=0) at av.c​:193
  #1 0x0807c454 in S_pad_findlex (name=0x811ad80 "%S", newoff=0, seq=3, startcv=0x812c5c8, cx_ix=2, saweval=0, flags=0) at op.c​:301
  for (cv = startcv; cv; cv = CvOUTSIDE(cv)) {
  AV *curlist = CvPADLIST(cv);
  --> SV **svp = av_fetch(curlist, 0, FALSE);
  AV *curname;
  #2 0x0807ca49 in Perl_pad_findmy (name=0x811ad80 "%S") at op.c​:497
  #3 0x08073c5f in S_pending_ident () at toke.c​:5243
  #4 0x08069c12 in Perl_yylex () at toke.c​:2201
  #5 0x0807a415 in Perl_yyparse () at perly.c​:1470
  #6 0x080c83d6 in S_doeval (gimme=128, startop=0x0) at pp_ctl.c​:2771

the immediate cause seems to be that S_pad_findlex tries to access an
uninitialized or corrupted cv, but that's unlikely to be the bug, as even
small modifications of the program make it work here (like replacing %S by
@​S, or the hashref {} by a string).

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.0:

Configured by root at Fri Jun 14 14:54:38 CEST 2002.

Summary of my perl5 (revision 5.0 version 8 subversion 0 patch 17236) configuration:
  Platform:
    osname=linux, osvers=2.4, archname=i686-linux
    uname='linux cerebro 2.4.18-pre8-ac3 #2 smp tue feb 5 17:35:23 cet 2002 i686 unknown '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef 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='gcc-2.95.4', ccflags ='-I/opt/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-Os -funroll-loops -mcpu=pentium -march=pentium -g',
    cppflags='-I/opt/include -D_GNU_SOURCE'
    ccversion='', gccversion='2.95.4 20010319 (prerelease)', 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-2.95.4', ldflags =''
    libpth=/usr/lib /opt/lib
    libs=-lcrypt -ldl -lm -lc
    perllibs=-lcrypt -ldl -lm -lc
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.2.5'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared'

Locally applied patches:
    DEVEL17205


@INC for perl v5.8.0:
    /root/src/sex
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    /opt/perl/lib/perl5
    .


Environment for perl v5.8.0:
    HOME=/root
    LANG (unset)
    LANGUAGE (unset)
    LC_CTYPE=de_DE@euro
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/root/s2:/root/s:/opt/qt/bin:/bin:/usr/bin:/usr/app/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/app/bin:/usr/app/sbin:/usr/X11/bin:/opt/jdk118/bin:/opt/bin:/opt/sbin:.:/root/cc/dejagnu/bin
    PERL5LIB=/root/src/sex
    PERLDB_OPTS=ornaments=0
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From @vanstyn

Marc Lehmann <root@​schmorp.de> wrote​:
:The following program segfaults with perl-devel and 5.6.1, but not with
:5.005_03​:
:
: $eval = eval 'sub { eval "sub { %S }" }';
: $eval->({});

At the point of coredump, pad_findlex() has followed the CvOUTSIDE chain
to a CV that isn't​:
  Program received signal SIGSEGV, Segmentation fault.
  Perl_av_fetch (av=0x22, key=0, lval=0) at av.c​:193
  193 if (SvRMAGICAL(av)) {
  (gdb) up
  #1 0x0808eb67 in S_pad_findlex (name=0x813e860 "%a", newoff=0, seq=3,
  startcv=0x814adf8, cx_ix=2, saweval=0, flags=0) at op.c​:301
  301 SV **svp = av_fetch(curlist, 0, FALSE);
  (gdb) p /x *cv
  $1 = {sv_any = 0x8141610, sv_refcnt = 0x1, sv_flags = 0x4040004}
  (gdb) p *(XPV*)cv->sv_any
  $2 = {xpv_pv = 0x8146e50 "sub { %a }\n;", xpv_cur = 12, xpv_len = 13}
  (gdb)
... and as far as I can tell this is because the particular CV has been
overfreed and thus reused​: its refcnt gets inc'd once in new_SV and
again in start_subparse() at​:
7550 CvOUTSIDE(PL_compcv) = (CV*)SvREFCNT_inc(outsidecv);
... and then dec'd once at op.c​:5055 (below) and again in freetmps().

I suspect the problem is this point here​:
  /* If a potential closure prototype, don't keep a refcount on outer CV.
  * This is okay as the lifetime of the prototype is tied to the
  * lifetime of the outer CV. Avoids memory leak due to reference
  * loop. --GSAR */
  if (!name)
  SvREFCNT_dec(CvOUTSIDE(cv));
... but I don't understand this area well enough to work out what is, and
what should, be happening.

Sarathy, can you shed any light?

Hugo

[p5pRT]

From @gsar

On Tue, 02 Jul 2002 18​:00​:49 BST, Hugo van der Sanden wrote​:

Marc Lehmann <root@​schmorp.de> wrote​:
​:The following program segfaults with perl-devel and 5.6.1, but not with
​:5.005_03​:
​:
​: $eval = eval 'sub { eval "sub { %S }" }';
​: $eval->({});

At the point of coredump, pad_findlex() has followed the CvOUTSIDE chain
to a CV that isn't​:
Program received signal SIGSEGV, Segmentation fault.
Perl_av_fetch (av=0x22, key=0, lval=0) at av.c​:193
193 if (SvRMAGICAL(av)) {
(gdb) up
#1 0x0808eb67 in S_pad_findlex (name=0x813e860 "%a", newoff=0, seq=3,
startcv=0x814adf8, cx_ix=2, saweval=0, flags=0) at op.c​:301
301 SV **svp = av_fetch(curlist, 0, FALSE);
(gdb) p /x *cv
$1 = {sv_any = 0x8141610, sv_refcnt = 0x1, sv_flags = 0x4040004}
(gdb) p *(XPV*)cv->sv_any
$2 = {xpv_pv = 0x8146e50 "sub { %a }\n;", xpv_cur = 12, xpv_len = 13}
(gdb)
... and as far as I can tell this is because the particular CV has been
overfreed and thus reused​: its refcnt gets inc'd once in new_SV and
again in start_subparse() at​:
7550 CvOUTSIDE(PL_compcv) = (CV*)SvREFCNT_inc(outsidecv);
... and then dec'd once at op.c​:5055 (below) and again in freetmps().

I suspect the problem is this point here​:
/* If a potential closure prototype, don't keep a refcount on outer CV.
* This is okay as the lifetime of the prototype is tied to the
* lifetime of the outer CV. Avoids memory leak due to reference
* loop. --GSAR */
if (!name)
SvREFCNT_dec(CvOUTSIDE(cv));
... but I don't understand this area well enough to work out what is, and
what should, be happening.

Sarathy, can you shed any light?

That test snippet doesn't coredump with perl-5.6.x-current. Perhaps
changes#13474,13478,13584 were never merged from 5.6.x into 5.7.x?

Sarathy
gsar@​ActiveState.com

[p5pRT]

From @gsar

On Tue, 02 Jul 2002 12​:09​:30 PDT, Gurusamy Sarathy wrote​:

That test snippet doesn't coredump with perl-5.6.x-current. Perhaps
changes#13474,13478,13584 were never merged from 5.6.x into 5.7.x?

change#16359 also looks relevant.

I thought all the 5.6.x changes made it into 5.8.0, but now I'm
not so sure. Can someone with the tuits verify this please?
Thanks.

Sarathy
gsar@​ActiveState.com

[p5pRT]

From @jhi

That test snippet doesn't coredump with perl-5.6.x-current. Perhaps
changes#13474,13478,13584 were never merged from 5.6.x into 5.7.x?

change#16359 also looks relevant. I thought all the 5.6.x changes
made it into 5.8.0, but now I'm not so sure. Can someone with the
tuits verify this please?

I grabbed a new sharp tuit spade and went out to the fields to dig
up some more. The #17407 attempts to (again) integrate the above
mentioned patches (effectively I cut and pasted the changed parts
of 5.6.1+ cv_undef() into bleadperl). In the past there were "issues"
(evilly twisted coredumps) after applying them, but now things seem
to work, maybe because the ithreads has matured in the meanwhile.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From [Unknown Contact. See original ticket]

On Sun, Jul 07, 2002 at 09​:36​:40PM +0300, Jarkko Hietaniemi <jhi@​iki.fi> wrote​:

up some more. The #17407 attempts to (again) integrate the above
mentioned patches (effectively I cut and pasted the changed parts
of 5.6.1+ cv_undef() into bleadperl). In the past there were "issues"
(evilly twisted coredumps) after applying them, but now things seem
to work, maybe because the ithreads has matured in the meanwhile.

I installed DEVEL17411 and found that my testcase works fine, but perl
still frequently coredumps after heavy eval activity. The thing is that
this seems to be connected to errors in the eval'ed code, which get
reported as warns(!!!) first and then using die. That is, when I overwrite
$SIG{__WARN__} I get messages like​:

  [Sat Jul 6 19​:47​:36 2002] [warn] Warning[8496]​: Scalar found where operator expected at mercury​::2_709​::edit line 1, near "#line 1 "mercury​::
  2_709​::edit"
  <?ef_selectbox { size => $arg"

which gets reported as a warning (but is an error), immediately followed by the same message as an error message.

undef'ing $SIG{__DIE__} and $SIG{__WARN__} seem to improve stability a
bit, but coredumps still happen. See also my other mail, which indicates
that context structures get overwritten.

(btw, all my reported bugs have been fixed really quickly, thanks a lot to
everybody!)

#0 0x400f295c in memcpy () from /lib/libc.so.6
#1 0x08c9500c in ?? ()
#2 0x0811ef98 in Perl_runops_standard () at run.c​:25
#3 0x080d95be in S_call_body (myop=0xbfffec7c, is_eval=0) at perl.c​:2045
#4 0x080d9186 in Perl_call_sv (sv=0x8346e30, flags=2) at perl.c​:1924
#5 0x08112979 in Perl_vcroak (pat=0x81a3ba0 "Can't locate object method \"%s\" via package \"%.*s\"", args=0xbfffed18) at util.c​:1285
#6 0x08112b10 in Perl_vwarn (pat=0x81a3ba0 "Can't locate object method \"%s\" via package \"%.*s\"", args=0x8440620) at util.c​:1350
#7 0x08126183 in S_method_common (meth=0x8a585e0, hashp=0xbfffed88) at pp_hot.c​:3154
#8 0x08125dd6 in Perl_pp_method_named () at pp_hot.c​:3039
#9 0x0811ef98 in Perl_runops_standard () at run.c​:25
#10 0x08145575 in S_docatch_body () at pp_ctl.c​:2536
#11 0x08145601 in S_docatch (o=0x8a3c058) at pp_ctl.c​:2572
#12 0x08147b9c in Perl_pp_entertry () at pp_ctl.c​:3435
#13 0x0811ef98 in Perl_runops_standard () at run.c​:25
#14 0x080d95be in S_call_body (myop=0xbfffefdc, is_eval=0) at perl.c​:2045
#15 0x080d9186 in Perl_call_sv (sv=0x8c7dffc, flags=66) at perl.c​:1924
#16 0x080d8fda in Perl_call_method (methname=0x81a308e "STORE", flags=2) at perl.c​:1857
#17 0x08117352 in S_magic_methcall (sv=0x8734808, mg=0x8c711e0, meth=0x81a308e "STORE", flags=2, n=3, val=0x8734808) at mg.c​:1317
#18 0x081175f1 in Perl_magic_setpack (sv=0x8734808, mg=0x8c711e0) at mg.c​:1354
#19 0x0811594e in Perl_mg_set (sv=0x8734808) at mg.c​:180
#20 0x0811f2e8 in Perl_pp_sassign () at pp_hot.c​:108
#21 0x0811ef98 in Perl_runops_standard () at run.c​:25
#22 0x080d95be in S_call_body (myop=0xbffff21c, is_eval=0) at perl.c​:2045
#23 0x080d9396 in Perl_call_sv (sv=0x81ef9e0, flags=4) at perl.c​:1963
#24 0x0806d4ef in perl_call_handler (sv=0x81ef9e0, r=0x8787dac, args=0x0) at mod_perl.c​:1658
#25 0x0806cfd2 in perl_run_stacked_handlers (hook=0x817907d "PerlHandler", r=0x8787dac, handlers=0x86e410c) at mod_perl.c​:1371
#26 0x0806c2c8 in perl_handler (r=0x8787dac) at mod_perl.c​:897
#27 0x080b2725 in ap_invoke_handler (r=0x8787dac) at http_config.c​:517

--
  -----==- |
  ----==-- _ |
  ---==---(_)__ __ ____ __ Marc Lehmann +--
  --==---/ / _ \/ // /\ \/ / pcg@​goof.com |e|
  -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
  The choice of a GNU generation |
  |

[p5pRT]

From @jhi

Since the original test case seems to be happy with Perl 5.8.0, I'm marking the problem ticket as resolved. (Maybe I'll add the test case to the Perl test suite while I'm at it.)

[p5pRT]

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