Re: [6.2] PROBLEMS file

Mark Kettenis
2004-07-22T19:26:30Z

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