This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [6.2] PROBLEMS file
> Date: Thu, 22 Jul 2004 21:26:18 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
>
> Date: Thu, 22 Jul 2004 22:11:06 +0200
> From: "Eli Zaretskii" <eliz@gnu.org>
>
> > #0 0x7ffe0304 in ?? ()
> > #1 0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
> > #2 0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
> > #3 0x00000778 in ?? ()
> > #4 0x00000000 in ?? () from
> > #5 0x010df2c8 in ?? ()
> > #6 0x000003e8 in ?? ()
> > [snip]
> > Previous frame inner to this frame (corrupt stack?)
> >
> > In the backtrace above, only frame 0 to 2 are correct. After that,
> > GDB goes in limbo until it finally finds out that something is wrong.
>
> That is exactly what I saw with the DJGPP port. Was the program in
> your case compiled with DWARF2 debug info or with some other format?
>
> Look at the backtrace Eli.
I did. It's possible that I misunderstand something, or even make
some stupid mistake, but there's no need to assume I didn't read the
message to which I responded.
> Frame #2 is executing Microsoft shit. I
> don't know what debugging format they use, and I don't think they ship
> their official releases with debugging info in it.
Sorry, I fail to see the relevance of this. No matter what debug info
is there, GDB should be able to track stack frames, shouldn't it? And
it actually does at least once: it succeeds in showing
WaitForSingleObjectEx as the caller of ntdll!ZwWaitForSingleObject.
Why can't it continue from there? Unless someone can prove to us (by
disassemblying at that spot) that the functions which give us trouble
are frameless, I'm not sure we should dismiss this case so easily.
> The code looks like hand-optimized assembler.
This needs a proof (unless you already looked at the machine code, in
which case please show it). In my experience, most of the ``Microsoft
shit'' is bad C with classic stack frames, not frameless
hand-optimized assembly.
Btw, Joel, could you please see if GDB 5.x did succeed to show a good
backtrace in this very case?
Anyway, the real reason I said what I did was that I see something
very similar in a DJGPP-compiled Emacs; see below. Now this is pure
GCC code and DJGPP runtime, no Microsoft shit anywhere in sight, and I
can tell you with 100% certainty that no hand-optimized assembly is
used anywhere in the frames that are misbehaving in GDB. It's all
part of Emacs sources written in C, you can actually look up the
sources in the Emacs codebase. Doesn't it look similar to what Joel
posted?
This is a snapshot of a session with GDB 5.1.1:
d:\gnu\new\emacs\src> gdb ./emacs
GNU gdb 5.1.1
Copyright 2002 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"...
Environment variable "DISPLAY" not defined.
Breakpoint 1 at 0x10b765: file msdos.c, line 4960.
(gdb) b q
(gdb) b dos_rawgetc
Breakpoint 2 at 0x108da0: file msdos.c, line 2263.
(gdb) r -q
Starting program: d:/gnu/new/emacs/src/./emacs -q
Breakpoint 2, 0x00108da0 in dos_rawgetc () at msdos.c:2263
2263 {
(gdb) c
Continuing.
Breakpoint 2, 0x00108da0 in dos_rawgetc () at msdos.c:2263
2263 {
(gdb) bt
#0 0x00108da0 in dos_rawgetc () at msdos.c:2263
#1 0x001098ac in dos_keysns () at msdos.c:2263
#2 0x000672b4 in read_avail_input (expected=0) at keyboard.c:6683
#3 0x0006718e in get_filtered_input_pending (addr=0x36d980, do_timers_now=1,
filter_events=1) at keyboard.c:6535
#4 0x0006ba7b in Finput_pending_p () at keyboard.c:9931
#5 0x000c6cda in Ffuncall (nargs=1, args=0x6de810) at eval.c:2725
#6 0x000f1b48 in Fbyte_code (bytestr=2106667, vector=2107772, maxdepth=96)
at bytecode.c:689
#7 0x000c6ff5 in funcall_lambda (fun=2106636, nargs=1, arg_vector=0x6de944)
at eval.c:2915
#8 0x000c6b9a in Ffuncall (nargs=2, args=0x6de940) at eval.c:2785
#9 0x000f1b48 in Fbyte_code (bytestr=2090427, vector=2091700, maxdepth=48)
at bytecode.c:689
#10 0x000c6ff5 in funcall_lambda (fun=2090404, nargs=0, arg_vector=0x6dea64)
at eval.c:2915
#11 0x000c6b9a in Ffuncall (nargs=1, args=0x6dea60) at eval.c:2785
#12 0x000f1b48 in Fbyte_code (bytestr=2085195, vector=2085348, maxdepth=48)
at bytecode.c:689
#13 0x000c6ff5 in funcall_lambda (fun=2085172, nargs=0, arg_vector=0x6deb20)
at eval.c:2915
#14 0x000c6e63 in apply_lambda (fun=2085172, args=3792897, eval_flag=1)
at eval.c:2837
#15 0x000c600f in Feval (form=5387093) at eval.c:2138
#16 0x0005fd92 in top_level_2 () at keyboard.c:1302
#17 0x000c4edd in internal_condition_case (bfun=0x5fd80 <top_level_2>,
handlers=3865009, hfun=0x5fa80 <cmd_error>) at eval.c:1335
#18 0x0005fe41 in top_level_1 () at keyboard.c:1310
#19 0x000c49fa in internal_catch (tag=3858225, func=0x5fe10 <top_level_1>,
arg=3792897) at eval.c:1096
#20 0x0005fcf8 in command_loop () at keyboard.c:1267
#21 0x0005f81d in recursive_edit_1 () at keyboard.c:978
#22 0x0005f955 in Frecursive_edit () at keyboard.c:1039
#23 0x0005dce8 in main (argc=2, argv=0x396b80) at emacs.c:1687
#24 0x00117092 in __crt1_startup ()
(gdb) q
The program is running. Exit anyway? (y or n) y
d:\gnu\new\emacs\src>
And this is the same session, for the same Emacs binary, with GDB 6.1:
d:\gnu\new\emacs\src> gdb6_1 ./emacs
GNU gdb 6.1
Copyright 2004 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 "--host=i386-pc-msdosdjgpp --target=djgpp"...
Environment variable "DISPLAY" not defined.
Breakpoint 1 at 0x10b765: file msdos.c, line 4960.
(gdb) b dos_rawgetc
Breakpoint 2 at 0x108da5: file msdos.c, line 2263.
(gdb) r -q
Starting program: d:/gnu/new/emacs/src/./emacs -q
Breakpoint 2, 0x00108da5 in dos_rawgetc () at msdos.c:2263
2263 {
(gdb) c
Continuing.
Breakpoint 2, 0x00108da5 in dos_rawgetc () at msdos.c:2263
2263 {
(gdb) bt
#0 0x00108da5 in dos_rawgetc () at msdos.c:2263
#1 0x001098ac in dos_keysns () at msdos.c:2263
#2 0x000672b4 in read_avail_input (expected=0) at keyboard.c:6683
#3 0x0006718e in get_filtered_input_pending (addr=0x36d980, do_timers_now=1,
filter_events=1) at keyboard.c:6535
#4 0x0006ba7b in Finput_pending_p () at keyboard.c:9931
#5 0x000c6cda in Ffuncall (nargs=1, args=0x6de810) at eval.c:2725
#6 0x000f1b48 in Fbyte_code (bytestr=2106667, vector=2107772, maxdepth=96)
at bytecode.c:689
#7 0x000c6ff5 in funcall_lambda (fun=2106636, nargs=1, arg_vector=0x6de944)
at eval.c:2915
#8 0x000c6b9a in Ffuncall (nargs=2, args=0x6de940) at eval.c:2785
#9 0x000f1b48 in Fbyte_code (bytestr=2090427, vector=2091700, maxdepth=48)
at bytecode.c:689
#10 0x000c6ff5 in funcall_lambda (fun=2090404, nargs=0, arg_vector=0x6dea64)
at eval.c:2915
#11 0x000c6b9a in Ffuncall (nargs=1, args=0x6dea60) at eval.c:2785
#12 0x000f1b48 in Fbyte_code (bytestr=2085195, vector=2085348, maxdepth=48)
at bytecode.c:689
#13 0x000c6ff5 in funcall_lambda (fun=2085172, nargs=0, arg_vector=0x6deb20)
at eval.c:2915
#14 0x000c6e63 in apply_lambda (fun=2085172, args=3792897, eval_flag=1)
at eval.c:2837
#15 0x000c600f in Feval (form=5387093) at eval.c:2138
#16 0x0005fd92 in top_level_2 () at keyboard.c:1302
#17 0x000c4edd in internal_condition_case (bfun=0x5fd80 <top_level_2>,
handlers=3865009, hfun=0x5fa80 <cmd_error>) at eval.c:1335
#18 0x0005fe41 in top_level_1 () at keyboard.c:1310
#19 0x000c49fa in internal_catch (tag=3858225, func=0x5fe10 <top_level_1>,
arg=3792897) at eval.c:1096
#20 0x0005fcf8 in command_loop () at keyboard.c:1267
#21 0x0005f81d in recursive_edit_1 () at keyboard.c:978
#22 0x0039e001 in end ()
#23 0x0039e001 in end ()
#24 0x0039e001 in end ()
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x006def08 in ?? ()
#28 0x0005f955 in Frecursive_edit () at keyboard.c:1039
Previous frame inner to this frame (corrupt stack?)
(gdb) q
The program is running. Exit anyway? (y or n) y
d:\gnu\new\emacs\src>