Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault on weird but plain Perl in eval on 5.10.0 on Windows #9503

Closed
p5pRT opened this issue Sep 30, 2008 · 9 comments
Closed

Segfault on weird but plain Perl in eval on 5.10.0 on Windows #9503

p5pRT opened this issue Sep 30, 2008 · 9 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 30, 2008

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

Searchable as RT59498$

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2008

From ebhanssen@cpan.org

Created by ebhanssen@cpan.org

  While tracking down the reasons for Test-Trap FAIL reports from
MSWin32 -- with good help from #Win32, in particular chorny -- we came
across the following simple Perl code​:

perl -le "eval q{ BEGIN{*CORE​::GLOBAL​::exit=sub{print q{Passed}}}if(fork){wait;exit}else{*CORE​::GLOBAL​::exit=sub{print q{Okay}};exit;CORE​::exit()} }"

  It passes on Unix with 5.8.8 or 5.10.0.

  It passes with ASPerl 5.8.8 and Cygwin perl 5.8.8.

  I don't have a Strawberry perl installation, but chorny was helpful
enough to try it on both 5.8.8 and 5.10.0, Strawberry perl.

  It passed with Strawberry perl 5.8.8.

  It segfaulted with Strawberry perl 5.10.0.

  I do know know if this is specific to Strawberry perl, or if it
affects all MSWin 5.10.0 perls.

  (I expect the code sample can be reduced further -- the prints are
likely irrelevant, and I don't know whether the *CORE​::GLOBAL​::exit
manipulation, the fork/wait, or both are relevant -- but without a
command line, I was disinclined to try.)

Thanks,
  Eirik

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.8:

Configured by root at Thu Feb 28 23:14:40 CST 2008.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.23.16-smp, archname=i486-linux-thread-multi
    uname='linux midas 2.6.23.16-smp #1 smp sat feb 23 00:20:30 cst 2008 i686 amd athlon(tm) 64 x2 dual core processor 5200+ authenticamd gnulinux '
    config_args='-de -Dprefix=/usr -Dvendorprefix=/usr -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Doptimize=-O2 -march=i486 -mtune=i686 -Dusethreads -Duseithreads -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.7 5.8.6 5.8.5 5.8.4 5.8.3 5.8.2 5.8.1 5.8.0 -Darchname=i486-linux'
    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='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -march=i486 -mtune=i686',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include'
    ccversion='', gccversion='4.2.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 =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.8:
    /usr/lib/perl5/5.8.8/i486-linux-thread-multi
    /usr/lib/perl5/5.8.8
    /usr/lib/perl5/site_perl/5.8.8/i486-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.8
    /usr/lib/perl5/site_perl/5.8.7
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.8/i486-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.8
    /usr/lib/perl5/vendor_perl
    .


Environment for perl v5.8.8:
    HOME=/home/eirik
    LANG=en_US
    LANGUAGE (unset)
    LC_COLLATE=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/local/bin:/usr/share/texmf/bin:/home/eirik/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented May 28, 2009

From @steve-m-hay

On Tue Sep 30 12​:46​:44 2008, ebhanssen@​cpan.org wrote​:

While tracking down the reasons for Test-Trap FAIL reports from
MSWin32 -- with good help from #Win32, in particular chorny -- we came
across the following simple Perl code​:

perl -le "eval q{ BEGIN{*CORE​::GLOBAL​::exit=sub{print
q{Passed}}}if(fork){wait;exit}else{*CORE​::GLOBAL​::exit=sub{print
q{Okay}};exit;CORE​::exit()} }"

(I expect the code sample can be reduced further -- the prints are
likely irrelevant, and I don't know whether the *CORE​::GLOBAL​::exit
manipulation, the fork/wait, or both are relevant -- but without a
command line, I was disinclined to try.)

Thanks for the report.

The bug is still present in bleadperl, and can be reduced to this​:

perl -eeval(q{if(!fork){exit}})

That crashes in perl-5.8.9 and perl-5.10.0, but not in perl-5.8.8. (All
default configuration builds using VC6.)

@p5pRT
Copy link
Author

p5pRT commented May 28, 2009

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

@p5pRT
Copy link
Author

p5pRT commented May 28, 2009

From @steve-m-hay

On Thu May 28 01​:20​:39 2009, shay wrote​:

The bug is still present in bleadperl, and can be reduced to this​:

perl -eeval(q{if(!fork){exit}})

Here's the stack trace from bleadperl​:

perl511.dll!Perl_gv_fetchpvn_flags(interpreter * my_perl=0x0183618c,
const char * nambeg=0x281e6650, unsigned int full_len=6, long flags=1,
const int sv_type=15) Line 1030 + 0x13 bytes C
  perl511.dll!Perl_gv_fetchpv(interpreter * my_perl=0x0183618c, const
char * nambeg=0x281e6650, long add=1, const int sv_type=15) Line 930 +
0x22 bytes C
  perl511.dll!win32_start_child(void * arg=0x0183618c) Line 1806 +
0x14 bytes C++
  kernel32.dll!7c80b729()
  [Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
  ntdll.dll!7c910222()
  ntdll.dll!7c91019b()

The isIDFIRST_lazy(name) call causes the crash​: name is okay (that's
"STDOUT") but isIDFIRST_lazy calls IN_BYTES which calls
CopHINTS_get(PL_curcop) which looks up PL_curcop->cop_hints, but
PL_curcop is NULL.

@p5pRT
Copy link
Author

p5pRT commented May 28, 2009

From @nwc10

Dave notes​:

crashes on 5.10.0 win32; okay on 5.8.8 or 5.10.0 unix
bug still new

@p5pRT
Copy link
Author

p5pRT commented May 28, 2009

From @steve-m-hay

On Thu May 28 04​:02​:39 2009, shay wrote​:

On Thu May 28 01​:20​:39 2009, shay wrote​:

The bug is still present in bleadperl, and can be reduced to this​:

perl -eeval(q{if(!fork){exit}})

Here's the stack trace from bleadperl​:

perl511.dll!Perl_gv_fetchpvn_flags(interpreter * my_perl=0x0183618c,
const char * nambeg=0x281e6650, unsigned int full_len=6, long flags=1,
const int sv_type=15) Line 1030 + 0x13 bytes C
perl511.dll!Perl_gv_fetchpv(interpreter * my_perl=0x0183618c, const
char * nambeg=0x281e6650, long add=1, const int sv_type=15) Line 930 +
0x22 bytes C
perl511.dll!win32_start_child(void * arg=0x0183618c) Line 1806 +
0x14 bytes C++
[...]

The isIDFIRST_lazy(name) call causes the crash​: name is okay (that's
"STDOUT") but isIDFIRST_lazy calls IN_BYTES which calls
CopHINTS_get(PL_curcop) which looks up PL_curcop->cop_hints, but
PL_curcop is NULL.

I've tracked down the change that caused this bug​:

http​://perl5.git.perl.org/perl.git/commitdiff/7c4baf4

@p5pRT
Copy link
Author

p5pRT commented Jun 26, 2009

From @steve-m-hay

See also 58468.

@p5pRT
Copy link
Author

p5pRT commented Jul 28, 2009

From @iabyn

fixed by f0c5aa0 in blead and pulled
into 5.10.1-tobe

@p5pRT
Copy link
Author

p5pRT commented Jul 28, 2009

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant