Re: [6.2] PROBLEMS file

[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.  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