Mail Archives: djgpp-workers/1999/05/19/04:21:14
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).
- Raw text -