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 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. 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.
The code looks like hand-optimized assembler. There is no hope our
unwinder can make any sense out of it without some major work. The
only thing that makes sense is somehow trust %ebp to point to some
valid frame. There is no guarantee that it doesn't point to some
garbage and if we trust it, we'll probably skip more a few frames in
the backtrace. That's why it won't be the default.
Mark