From SCUSACK@bloomberg.net

Created by scusack@bloomberg.net

err.in​:

1234567890
1234567890 1234567890
1234567890 1234567890 1234567890
1234567890 1234567890

err.pl​:

#!/usr/local/bin/perl

print "without fork, this works​:\n";
open( ERR, "err.in" );
while( <ERR> )
{
  print $_;
}
close(ERR);

print "with fork, even though the child does nothing, this loops forever, ".
  "because the fork somehow resets the parent's filehandle​:\n";
open( ERR, "err.in" );
while( <ERR> )
{
  print $_;
  if( !fork() ) { exit(0); }
  wait();
}
close(ERR);

Site configuration information for perl 5.00503:

Configured by ascotti at Wed Apr 21 08:16:55 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.6, archname=sun4-solaris
    uname='sunos tkr27 5.6 generic_105181-13 sun4u sparc sunw,ultra-enterprise '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O', gccversion=
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/local/lib/perl5/5.00503/sun4-solaris
    /usr/local/lib/perl5/5.00503
    /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
    /usr/local/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/home/scusack
    LANG (unset)
    LANGUAGE (unset)
    
LD_LIBRARY_PATH=/bb/bin/informix/ifmx7.3/lib:/bb/bin/informix/ifmx7.3/lib/esql:
    LOGDIR (unset)
    
PATH=/bbsrc/tools/bbcm:/usr/atria/bin:/bin:/usr/bin:/usr/sbin::/usr/bin/X11:/usr
/local/bin:/bb/bin:/home/scusack/scripts:/home/scusack/bin:/opt/SUNWspro/bin
    PERL_BADLANG (unset)
    SHELL=/usr/bin/ksh

From @eserte

"SEAN CUSACK, BLOOMBERG/ 499 PARK" (via RT) <perlbug@​perl.org> writes​:

# New Ticket Created by "SEAN CUSACK, BLOOMBERG/ 499 PARK"
# Please include the string​: [perl #17711]
# in the subject line of all future correspondence about this issue.
# <URL​: http​://rt.perl.org/rt2/Ticket/Display.html?id=17711 >

Cc​: ascotti@​bloomberg.net

This is a bug report for perl from scusack@​bloomberg.net,
generated with the help of perlbug 1.26 running under perl 5.00503.

-----------------------------------------------------------------
[Please enter your report here]

err.in​:

1234567890
1234567890 1234567890
1234567890 1234567890 1234567890
1234567890 1234567890

err.pl​:

#!/usr/local/bin/perl

print "without fork, this works​:\n";
open( ERR, "err.in" );
while( <ERR> )
{
print $_;
}
close(ERR);

print "with fork, even though the child does nothing, this loops forever, ".
"because the fork somehow resets the parent's filehandle​:\n";
open( ERR, "err.in" );
while( <ERR> )
{
print $_;
if( !fork() ) { exit(0); }
wait();
}
close(ERR);

[Please do not change anything below this line]
-----------------------------------------------------------------

Maybe this is Solaris specific. I can't reproduce the problem on
FreeBSD with perl 5.00503, 5.6.1, and 5.8.0.

Regards,
  Slaven

---
Site configuration information for perl 5.00503​:

Configured by ascotti at Wed Apr 21 08​:16​:55 EDT 1999.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration​:
Platform​:
osname=solaris, osvers=2.6, archname=sun4-solaris
uname='sunos tkr27 5.6 generic_105181-13 sun4u sparc sunw,ultra-enterprise '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler​:
cc='cc', optimize='-O', gccversion=
cppflags='-I/usr/local/include'
ccflags ='-I/usr/local/include'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
alignbytes=8, usemymalloc=y, prototype=define
Linker and Libraries​:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches​:

---
@​INC for perl 5.00503​:
/usr/local/lib/perl5/5.00503/sun4-solaris
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
.

---
Environment for perl 5.00503​:
HOME=/home/scusack
LANG (unset)
LANGUAGE (unset)

LD_LIBRARY_PATH=/bb/bin/informix/ifmx7.3/lib​:/bb/bin/informix/ifmx7.3/lib/esql​:
LOGDIR (unset)

PATH=/bbsrc/tools/bbcm​:/usr/atria/bin​:/bin​:/usr/bin​:/usr/sbin​::/usr/bin/X11​:/usr
/local/bin​:/bb/bin​:/home/scusack/scripts​:/home/scusack/bin​:/opt/SUNWspro/bin
PERL_BADLANG (unset)
SHELL=/usr/bin/ksh

--
Slaven Rezic - slaven.rezic@​berlin.de

  tktimex - project time manager
  http​://sourceforge.net/projects/ptktools/

From SCUSACK@bloomberg.net

Slaven,

Yes, it is solaris-specific. But is there anything perl itself can do to have
this work in a platform-independent manner? It works fine on 3 other
architectures under perl5.005_03, perl5.6, and perl5.8, but not any of those
under solaris.

--Sean

From @Hugmeir

On Tue Oct 01 15​:01​:12 2002, scusack wrote​:

Slaven,

Yes, it is solaris-specific. But is there anything perl itself can do
to have
this work in a platform-independent manner? It works fine on 3 other
architectures under perl5.005_03, perl5.6, and perl5.8, but not any of
those
under solaris.

--Sean

I could reproduce this on Solaris 10 with the system-provided 5.8.4, but
everything from 5.10.1 to blead works as expected. I'm assuming that
this and other similar tickets were resolved when fork() started
autoflushing filehandles in Solaris, so I vote to close this.

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

From @nwc10

On Sat, Apr 28, 2012 at 02​:22​:39AM -0700, Brian Fraser via RT wrote​:

On Tue Oct 01 15​:01​:12 2002, scusack wrote​:

Slaven,

Yes, it is solaris-specific. But is there anything perl itself can do
to have
this work in a platform-independent manner? It works fine on 3 other
architectures under perl5.005_03, perl5.6, and perl5.8, but not any of
those
under solaris.

--Sean

I could reproduce this on Solaris 10 with the system-provided 5.8.4, but
everything from 5.10.1 to blead works as expected. I'm assuming that
this and other similar tickets were resolved when fork() started
autoflushing filehandles in Solaris, so I vote to close this.

I ran this with the test script tweaked with C<alarm 10;>​:

../perl/Porting/bisect.pl --expect-fail --target miniperl --start perl-5.8.0 ../17711.pl

It says​:

commit 15b61c9
Author​: Jarkko Hietaniemi <jhi@​iki.fi>
Date​: Mon Apr 21 06​:50​:42 2003 +0000

  Introduce two new Configure symbols​:
  [1] d_faststdio = d_stdstdio && d_stdio_ptr_lval &&
  (d_stdio_cnt_lval || d_stdio_ptr_lval_sets_cnt)
  [2] usefaststdio = do we use fast stdio if we have it?
  For 5.[68], we do. For anything else, we don't.
  (At least, unless otherwise instructed by -Dusefaststdio.)
  This means that for bleadperl we no more use stdio, but instead
  default to perlio​: the effect of PERLIO=perlio, in other words.
  (PERLIO=stdio will still switch to using stdio.)
  This change may endanger extensions using FILE*-- but if we are
  to migrate fully to perlio, better start swallowing the poison now.
  For maintperl, the usefaststdio still defaults to yes.

  p4raw-id​: //depot/perl@​19286

:100755 100755 f7a40505e0d66103dd6a89983c12ea1a3309ed36 b8116b9c362c6e572854470492ac89086913e400 M Configure
:100644 100644 da9a6c2bdeab400d09d6cd4fce1d1677eefebe55 fea578d325bffc7e3c560a4233f5e3a901e14458 M config_h.SH
:100644 100644 e6c985cd27db201c60b863a3e58dffacf1faf490 63a159f00542c90e4b972c2a524e18e3b9eeec47 M perlio.c
:040000 040000 887682f310965ada6a5a79c0f7a376944bc89db5 30fbe296553f3c4ed3055c00bfdd1048d6dfe545 M t
bisect run success
That took 1753 seconds

So, if I try the script with system perl like this​:

$ PERLIO=perlio perl ../17711.pl
without fork, this works​:
1234567890
1234567890 1234567890
1234567890 1234567890 1234567890
1234567890 1234567890
with fork, even though the child does nothing, this loops forever, because the fork somehow resets the parent's filehandle​:
1234567890
1234567890 1234567890
1234567890 1234567890 1234567890
1234567890 1234567890

it now exits cleanly rather than looping.

and if I run blead (ish - what I had handy) like this​:

$ PERLIO=stdio ~/Sandpit/R/bin/perl5.15.2 ../17711.pl

it loops, as before.

So, at this point, it looks like this bug isn't totally resolved.

*Except*, this is the man page for fork(2) on Solaris​:

NOTES
  An application should call _exit() rather than exit(3C) if
  it cannot execve(), since exit() will flush and close stan-
  dard I/O channels and thereby corrupt the parent process's
  standard I/O data structures. Using exit(3C) will flush

SunOS 5.11 Last change​: 28 Oct 2008 6

System Calls fork(2)

  buffered data twice. See exit(2).

[I'd already tested that replacing exit() with POSIX​::_exit() made it
work]

So, the program using exit() is hitting a documented caveat of Solaris
fork - "corrupt the parent process's standard I/O data structures".
Perl's documentation for fork does reference the system call, but doesn't
mention POSIX​::_exit(). Should it? Does the POSIX standard have a strong
opinion about fork?

Nicholas Clark

From @cpansprout

On Tue May 01 03​:27​:12 2012, nicholas wrote​:

So, at this point, it looks like this bug isn't totally resolved.

Do you suggest we re-open it, then?

--

Father Chrysostomos

From @nwc10

On Tue, May 01, 2012 at 08​:38​:00AM -0700, Father Chrysostomos via RT wrote​:

On Tue May 01 03​:27​:12 2012, nicholas wrote​:

So, at this point, it looks like this bug isn't totally resolved.

Do you suggest we re-open it, then?

Well, IIRC from the part you trimmed, the questions were about documentation
in perlfunc.pod

The original reported problem in the script is that it's tripping up on a
documented behaviour of the interaction of fork() on Solaris with stdio.
(Solaris does, or at least did, seek the underlying file handles at exit
when cleaning up stdio, after flushing buffers.)

That's not really a perl interpreter behaviour bug.

Nicholas Clark