Re: gdb stack trace problems

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 18, 2005 at 03:47:02PM +0200, Roland Schwingel wrote:
> Ok... Thought that would be already known in a broader space, as after 
> asking
> google for gdb stack trace problems there had been some hits but none with a
> good answer...

Saying "stack trace problems" for GDB is like saying "my code doesn't
compile" for GCC.  It doesn't tell us very much about what has gone
wrong; stack backtracing is a complex problem with lots of
dependencies.

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 2316.0xf8c]
> 0x0040131d in crashIfZero (num=2) at gdbtest.c:17
> 17                      *data=911;
> (gdb) thr 1
> [Switching to thread 1 (thread 2316.0xf10)]#0  0x7c91eb94 in 
> ntdll!LdrAccessResource () from ntdll.dll
> (gdb) bt
> #0  0x7c91eb94 in ntdll!LdrAccessResource () from ntdll.dll
> #1  0x7c91d85c in ntdll!ZwDelayExecution () from ntdll.dll
> #2  0x7c8023ed in SleepEx () from /vol/c/WINDOWS/system32/kernel32.dll
> #3  0x00000000 in ?? () from

OK, here's a concrete problem.  GDB 6.x has a (usually) more reliable
prologue analyzer for x86, compared to GDB 5.3.  However, the old one
got lucky with SleepEx and the new one doesn't.  I'd ask you to post
disassembly of the function except I'm not sure how wise that is with a
Microsoft DLL...

Mark, you did the work on the i386 prologue analyzer.  Any chance you
could take a look at this?


-- 
Daniel Jacobowitz
CodeSourcery, LLC