Date: Sat, 26 Apr 2003 12:04:27 +0300 From: "Eli Zaretskii" 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 Precedence: bulk > 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