Mail Archives: djgpp-workers/1999/05/17/14:40:29
> With this version, I still get the annoying message when I quit GDB
> 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:
I generated a gdb with a modified _open.c and _close.c which
prints to stderr the opened/closed filehandles. Additionally
I built emacs with _openc.c so I can set there a breakpoint.
Then I had the following debug session: (my comments start with
#)
C:\TEMP\EM\EMACS-20.3\SRC>gdb emacs
GDB: open(c:\djgpp\djgpp.env) => 5
GDB: close(5)
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-pc-msdosdjgpp"...GDB: open(emacs) => 5
GDB: open(emacs) => 6
#NOTE: GDB open the file emacs with fd's 5 and 6 !!!]
(gdb) b _close
Breakpoint 1 at 0xa7ba5: file _close.c, line 16.
(gdb) r
GDB: open(c:/temp/em/emacs-20.3/src/emacs) => 7
Starting program: c:/temp/em/emacs-20.3/src/emacs
GDB: open(c:/temp/em/emacs-20.3/src/emacs) => 7
GDB: close(7)
GDB: close(7)
Breakpoint 1, _close (handle=7) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 8
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(8)
GDB: close(8)
(gdb) c
# some repeated output snipped
# pressing c until I come to the main screen of emacs and
# then pressing C-x C-c]
Breakpoint 1, _close (handle=8) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 9
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(9)
GDB: close(9)
Breakpoint 1, _close (handle=7) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 8
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(8)
GDB: close(8)
(gdb) c
Continuing.
Breakpoint 1, _close (handle=4) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 7
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(7)
GDB: close(7)
# why does emacs close here the handle 4?
(gdb) c
Continuing.
Breakpoint 1, _close (handle=3) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 4
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(4)
GDB: close(4)
(gdb) c
Continuing.
Breakpoint 1, _close (handle=5) at _close.c:16
GDB: open(c:/temp/em/emacs-20.3/src/_close.c) => 3
16 __FSEXT_Function *func = __FSEXT_get_function(handle);
GDB: close(3)
GDB: close(3)
# why does emacs close here the handle 5? !!!!!
(gdb) c
Continuing.
Program exited normally.
GDB: open(c:/temp/em/emacs-20.3/src/emacs) => 3
(gdb) c
The program is not being run.
(gdb) q
GDB: close(5)
GDB: close(5)
warning: cannot close "c:/temp/em/emacs-20.3/src/emacs": Bad file descriptor (EB
ADF)
GDB: close(4)
GDB: close(3)
GDB: close(3)
GDB: close(6)
GDB: close(6)
As you can see, emacs close more filehandles then it should. The problematic
part is here, that it closes also the handle 5 which is owned by GDB!!
BTW: If you redirect stdout or stderr during the debug session, the
problem does not occour:
redir -e err gdb emacs
> Another problem is that when I restart the program (with `r'), GDB
> asks whether I indeed want to restart it. If the program has switched
> stdin to binary mode, the machine is wedged at this point. The same
> happens if I try to quit the debugger before program termination, when
> it asks for confirmation.
For this I have now the patch for gdb which I will send in a separate mail.
> Perhaps libgdb.a (the one you use to build RHIDE) should also be
> included, if it's not too much trouble to build it.
It is really not trouble, but it will increase the bin archive by about
1.3MB. After the final gdb distrib I will upload a separate libgdb
archive.
> - The file NEWS should be included (README.DJGPP even refers to it).
I simply forgot it.
> - I think at least the main DJGPP-specific changes relative to the
> last DJGPP port (4.16) should also be mentioned, because NEWS will
> not describe them.
I'll try to remember them all and writing them down.
> - I think it's best to distribute man pages already formatted (and
OK.
> - Perhaps README.DJGPP should tell how to update info/DIR, either by
> running install-info or by editing DIR. I think most people won't
I'll do, even you made already the changes for DJGPP 2.03 in the CVS.
Robert
******************************************************
* email: Robert Hoehne <robert DOT hoehne AT gmx DOT net> *
* Post: Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW: http://www.tu-chemnitz.de/~sho/rho *
******************************************************
- Raw text -