Date: Wed, 19 May 1999 11:18:44 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Robert Hoehne cc: djgpp-workers AT delorie DOT com Subject: Re: gdb 4.18 for DJGPP (alpha) In-Reply-To: <199905171838.VAA14771@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 17 May 1999, Robert Hoehne wrote: > > after exiting Emacs that was run under the debugger: > > > > warning: cannot close "e:/src/gnu/emacs/emacs": Bad file descriptor (EBADF) > > > > This message doesn't get printed if I quit GDB *before* exiting Emacs. > > > > Please tell me how can I help you to try to track down this elusive bug. > > May the following will help you to remove the bug in emacs which it > is in my opinion: Like I said yesterday, this is a library bug. When a program (any DJGPP program) exits, the exit code walks all the FILE objects and flushes and closes every one of them (the fclose is only done if the associated file handle is 3 or larger). So the parts of the script that show handles 3 and 4 closed are normal behavior. Handle 5 is closed because the FILE object which used it during the dump procedure is left frozen in the Emacs executable and looks to the exit code as a normal FILE object. I checked in a change in the startup code that forces initialization of the FILE objects' list instead of relying on static initialization. This solved the bug for me. Thanks again for looking into this. > BTW: If you redirect stdout or stderr during the debug session, the > problem does not occour: > > redir -e err gdb emacs This is a coincidence: redir dup()'s its stdout before launching GDB (so that it could report any errors to the screen even though stdout and stderr could be redirected). The call to dup() creates a new handle, number 5, which is inherited by GDB. So the first handle available to GDB is 6, which is used to open the debuggee file, and therefore the bug doesn't happen because Emacs has only one stale handle, handle 5, frozen in its image (when Emacs dumps itself, there's only one file open as a FILE object).