This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb stack trace problems
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: drow at false dot org
- Cc: roland dot schwingel at onevision dot de, gdb at sources dot redhat dot com
- Date: Mon, 18 Apr 2005 19:10:57 +0200 (CEST)
- Subject: Re: gdb stack trace problems
- References: <4263BA56.9080509@onevision.de> <20050418135721.GA5332@nevyn.them.org>
Date: Mon, 18 Apr 2005 09:57:21 -0400
From: Daniel Jacobowitz <drow@false.org>
> 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?
Sure if someone can provide me with the dissassembly in AT&T syntax
for that function, or even better some assembler code that exhibits
the problem. No promises though that I'll fix this. Last time I
looked at some windows disassembler it looked like it was hand
optimized in such a way that the entire function needed to be analyzed
to do something useful; something that doesn't quite fit in the way we
do things in GDB.
Mark