develooper Front page | perl.perl5.porters | Postings from February 2003

[perl #21382] exit()/exec() crashes Perl after fork

Lippmann Jens,E2
February 27, 2003 06:34
[perl #21382] exit()/exec() crashes Perl after fork
Message ID:
# New Ticket Created by  "Lippmann Jens,E2" 
# Please include the string:  [perl #21382]
# 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.33 running under perl v5.6.1.

[Please enter your report here]

I'm into Perl for more than 8 years and I cannot overemphasize that I
appreciated every single minute programming with it.

Now, I actually spent quite a large amount of time to find a nasty bug
that crashes Perl on Windows NT when I call fork and exec.
The problem is not related to any specific Perl but rather sticks to Perl
ports that create threads instead of processes.
As soon as the exec'd task terminates there is a considerable high chance
(obviously a race condition) to crash perl.
When I replace exec() with system() and exit() the problem pertains, but
not if I use system() and POSIX::_exit().

I am sending this bug report to the mainstream Perl development
instead of any specific Win32 support group such as ActiveState or
Indigo just because the 'bug' I am referring herein seems to be
related in a deficient Perl documentation on this topic.

My pledge is to build up a FAQ topic (perldoc -q) for fork that helps
out of this remedy, and to extend the fork/exec sections in the
perlfuncs doc module, and to overhaul the notorious
 'if ($pid = fork()) { ... } else { ... exec/exit; }'
examples that are used throughout the perlipc doc.

It is generally a bad idea to use exit() after fork(), unless you want to
create a daemon process (see
 "1.1.3 Why use_exit rather than exit in the child branch of a fork?").
It is also a bad idea to use exec() after fork() on a Win32 port for the simple
reason that exec() itself performs cleanup action on process termination
similar to exit().

It is no good way to leave the user undocumented and let the
developers run into the same obstacles again with every new release.
Meanwhile there are half a dozen Win32 module extensions on CPAN, but
none seems to come with support throughout all Win32 platforms or
availability for any perl distribution.
For the sake of transparency and portability, why can't Perl itself
solve the exit handling to smooth out thread and non-thread forks?
I recommend to either
 - keep the transparency of fork() but then make exit() transparent as well
   (i.e. remember the 'thread' state and act accordingly), or
 - do not support fork() on Win32 but vfork() and provide a function like

I further recommend to generally incorporate POSIX::_exit() into the
Perl core and to add a hint about the batch command 'start' which can
be used to conveniently spawn a task under Win32.

kind regards
Jens Lippmann

[Please do not change anything below this line]
Site configuration information for perl v5.6.1:

Configured by Indy at Sun May  6 21:35:42 2001.

Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    optimize='-O1 -MD -DNDEBUG',
    ccversion='', 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='off_t', lseeksize=4
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='', ldflags ='-nologo -nodefaultlib -release  -libpath:"f:\dev\dp\perl-5.6_install\lib\CORE"  -machine:x86'
    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 wsock32.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 wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  -libpath:"f:\dev\dp\perl-5.6_install\lib\CORE"  -machine:x86'

Locally applied patches:

@INC for perl v5.6.1:

Environment for perl v5.6.1:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PERL_BADLANG (unset)
    SHELL (unset) Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About