Date:	Sat, 26 Apr 2003 12:04:27 +0300
From:	"Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	sandmann AT clio DOT rice DOT edu
Message-Id:	<7443-Sat26Apr2003120426+0300-eliz@elta.co.il>
X-Mailer:	emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<10304260336.AA19080@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: 2.04 status page / 2.04 alpha 1 release schedule
References:	<10304260336 DOT AA19080 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Fri, 25 Apr 2003 22:36:48 -0500 (CDT)
> 
> > But I don't understand how a child can mess up the parent's environment. If a
> > child program closes inherited file descriptors, how does that affect the
> > parent program? Maybe I'm missing something here. I'm also not sure how the
> > parent would notice, unless __setup_file_rec_list is called after the child
> > has terminated. (I don't think it is.)
> 
> What happens is the program does an unconditional close of the handles 3 and
> 4 because they are assumed to be associated with stdaux/stdprn during 
> exit file rundown, which corrupts the internal buffering.  Maybe it's 
> just the child that is corrupted, I can't remember.  Now when we set up 
> those file descriptors, if 3 and 4 aren't there we flag them so they don't 
> get closed at exit before the real file descriptors they were used with
> (which leaves them to be flushed properly).

IIRC, only the program which has handle 3 or 4 closed on startup gets
hit: if it fopen's some file, that file's FILE object gets handle 3 or
4, and the data wrotten to that FILE object does not get flushed when
our exit code fclose's all active FILE objects in stdiohk.c.

The relation of this to parent/child issue is that Perl closes handles
3 and 4 in its startup code, so any DJGPP program run by Perl suffers
from this problem.  This is how the bug was discovered: Perl would run
m4 with a debug option, and the data written by m4 to the debug file
did not appear in the file.  To a naive user, that looks like a bug in
Perl (i.e. in the parent program).

The thread where the problem was diagnosed and discussed is available
in the archives of this mailing list starting with this message:

 http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2001/09/23/11:21:59

For the description of the original bug and the initial discussions
of its possible causes, see this thread:

 http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2001/08/14/16:27:37

- Raw text -