From alex.davies@talktalk.net

Created by alex@Amelie

On windows XP with 5.10 running​:

  perl.exe -e "do 'test.pl'

triggers an exception (5.8.7 works ok). "test.pl" is​:

  print "parent $$\n";
  if (fork() == 0) {
  print "child $$\n";
  exit;
  }

Simply running the test file as "perl test.pl" does not
trigger an exception.

Running it under VS6, it bombs out in PERL_WAIT_FOR_CHILDREN
in perl_destruct(). By inlining the actual macro code and
recompiling, it appears the exception occurs in the
WaitForMultipleObjects() call. (fwiw - the function args look
reasonable).

Can anyone else reproduce this?

thanks.

Flags:
    category=core
    severity=medium

This perlbug was built using Perl 5.10.0 - Mon Aug 11 04:41:10 2008
It is being executed now by  Perl 5.10.0 - Sat Aug 30 16:37:01 2008.

Site configuration information for perl 5.10.0:

Configured by alex at Sat Aug 30 16:37:01 2008.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=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='cl', ccflags 
='-nologo -GF -W3 -Od -MD -Zi -DDEBUGGING -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT 
  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-Od -MD -Zi -DDEBUGGING',
    cppflags='-DWIN32'
    ccversion='12.00.8804', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', 
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags 
'-nologo -nodefaultlib -debug  -libpath:"c:\perl\lib\CORE"  -machine:x86'
    libpth=C:\PROGRA~1\MICROS~4\VC98\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib 
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib 
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=true, libperl=perl510.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', 
ddlflags='-dll -nologo -nodefaultlib -debug  -libpath:"c:\perl\lib\CORE"  -machine:x86'

Locally applied patches:



@INC for perl 5.10.0:
    C:/alex/src/perl/perl-5.10.0.tar/perl-5.10.0/lib
    .


Environment for perl 5.10.0:
    HOME=C:\alex
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\PROGRA~1\MICROS~4\Common\msdev98\BIN;C:\PROGRA~1\MICROS~4\VC98\BIN;C:\PROGRA~1\MICROS~4\Common\TOOLS\WINNT;C:\PROGRA~1\MICROS~4\Common\TOOLS;C:\Program 
Files\Ruby-185-21\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\alex\bin;C:\Program 
Files\Microsoft SDK\Bin\.;C:\Program Files\Microsoft SDK\Bin\WinNT\.;C:\Program 
Files\Tcl-8.5.0\bin;C:\PerlAPPv9\bin;C:\Program 
Files\QuickTime\QTSystem\;C:\strawberry\c\bin;C:\strawberry\perl\bin;C:\Program 
Files\Microsoft Visual Studio\VC98\Bin;C:\Program Files\Microsoft 
SDK\Bin\.;C:\Program Files\Microsoft SDK\Bin\WinNT;C:\cygwin\bin
    PERL_BADLANG (unset)
    SHELL (unset)

From alex.davies@talktalk.net

On windows XP with 5.10 running​:

perl.exe -e "do 'test.pl'

triggers an exception (5.8.7 works ok). "test.pl" is​:

print "parent $$\n";
if (fork() == 0) {
print "child $$\n";
exit;
}

Simply running the test file as "perl test.pl" does not
trigger an exception.

Running it under VS6, it bombs out in PERL_WAIT_FOR_CHILDREN
in perl_destruct(). By inlining the actual macro code and
recompiling, it appears the exception occurs in the
WaitForMultipleObjects() call. (fwiw - the function args look
reasonable).

ok - ignore that analysis... wrong thread :-\

It's crashing in a call to Perl_gv_fetchpvn_flags() done
from the do_close(..."STDOUT"...) in win32_start_child()

The problem is at the isIDFIRST_lazy(name).

Tracing the macros​:

/* (1) utf8.h 167 */
#define isIDFIRST_lazy(p) isIDFIRST_lazy_if(p,1)

/* (2) utf8.h 155 */
#define isIDFIRST_lazy_if(p,c) ((IN_BYTES || (!c || (*((const U8*)p) < 0xc0))) \
  ? isIDFIRST(*(p)) \
  : isIDFIRST_utf8((const U8*)p))

/* (3) utf8.h 191 */
#define IN_BYTES (CopHINTS_get(PL_curcop) & HINT_BYTES)

/* (4) cop.h 270 */
#define CopHINTS_get(c) ((c)->cop_hints + 0)

...and my_perl->Icurcop is NULL. Hence the exception.

It gets set to NULL when pp_exit() ends up calling Perl_parser_free() which​:

  // toke.c ~737
  PL_curcop = parser->saved_curcop;

...and that is NULL.

HTH

Thanks,
alex.

From @nwc10

Dave notes​:

5.10.0 regression following a null PL_curcop under windows.
I can't reproduce it on Linux.

@nwc10 - Status changed from 'new' to 'open'

From @steve-m-hay

Looks like the same bug as 59498. Is it something to do with the
implicit host layer on Win32 (explaining why it isn't reproducible on
linux)?

From alex.davies@talktalk.net

----- Original Message -----
From​: "Steve Hay via RT" <perlbug-followup@​perl.org>
To​: <alex.davies@​talktalk.net>
Sent​: Friday, June 26, 2009 3​:35 PM
Subject​: [perl #58468] crash on exit with fork done in do FILE on Win32

Looks like the same bug as 59498. Is it something to do with the
implicit host layer on Win32 (explaining why it isn't reproducible on
linux)?

The stack trace in the 59498 summary is identical to what
i was getting with 58468.

I've just manually undone the change that you identified [*] as
breaking this on my blead perl and it no longer crashes. Yay!

Unfortunately the patch description (which is "save old
PL_curcop value in parser struct") doesn't explain why the
change was necesary.

alex.

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

From @iabyn

On Mon, Jul 06, 2009 at 05​:59​:47PM +0100, alex.davies@​talktalk.net wrote​:

----- Original Message ----- From​: "Steve Hay via RT"
<perlbug-followup@​perl.org>
To​: <alex.davies@​talktalk.net>
Sent​: Friday, June 26, 2009 3​:35 PM
Subject​: [perl #58468] crash on exit with fork done in do FILE on Win32

Looks like the same bug as 59498. Is it something to do with the
implicit host layer on Win32 (explaining why it isn't reproducible on
linux)?

The stack trace in the 59498 summary is identical to what
i was getting with 58468.

I've just manually undone the change that you identified [*] as
breaking this on my blead perl and it no longer crashes. Yay!

Unfortunately the patch description (which is "save old
PL_curcop value in parser struct") doesn't explain why the
change was necesary.

I;ve just applied f0c5aa0 to blead, which
may fix this. At least, it fixes a fault in 7c4baf4.

This is determined by visual inspection, since I don't have access to
Windows. Can anyone confirm whether it fixes those two bugs? (And may
write a test case?)

Thanks.

--
My Dad used to say 'always fight fire with fire', which is probably why
he got thrown out of the fire brigade.

From @jandubois

On Sat, 25 Jul 2009, Dave Mitchell wrote​:

On Mon, Jul 06, 2009 at 05​:59​:47PM +0100, alex.davies@​talktalk.net wrote​:

The stack trace in the 59498 summary is identical to what
i was getting with 58468.

I've just manually undone the change that you identified [*] as
breaking this on my blead perl and it no longer crashes. Yay!

Unfortunately the patch description (which is "save old
PL_curcop value in parser struct") doesn't explain why the
change was necesary.

I;ve just applied f0c5aa0 to blead, which
may fix this. At least, it fixes a fault in 7c4baf4.

This is determined by visual inspection, since I don't have access to
Windows. Can anyone confirm whether it fixes those two bugs? (And may
write a test case?)

I can confirm that the sample code from both bug reports now runs
without throwing an exception on Windows.

Cheers,
-Jan

From @iabyn

fixed in blead by f0c5aa0 and pulled
into 5.10.1-tobe

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