Re: gdb stack trace problems (Addendum)

[Roland Schwingel <roland.schwingel@onevision.de>]

Hi...

Mark Kettenis <mark.kettenis@xs4all.nl> wrote on 25.04.2005 21:26:32:
 > Can you test the attached patch?  It introduces a new option named
 > "trust-frame-pointer".  Whenever you encounter a problem you can:
 >
 > (gdb) set trust-frame-pointer 1
 >
 > and try again.  You probably want to reset it to 0 before continuing
 > your program since I found out that bad things happen with some of the
 > tests in the gdb testsuite with this turned on.

I couldn't resist and checkin out and compiling went without problems so
I tried it out immediately... I did run my gdbtest app again (the one I 
posted
to the list on 20050418). Here are the results. As you will see immediately
it looks now differently. There is no longer a SleepEx() in the stack.
Instead there is no a Sleep() but unfortunately the frame gets duplicated
and afterwards gdb complains about a maybe corrupt stack. See attached
output.

Roland

gdb.exe ./gdbtest.exe
GNU gdb 6.3.50.20050426-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /tmp/gdbtest.exe
test gdb stack tracing during a crash
Created thread 1 with ID: 2472
I am thread 1 and alive
Created thread 2 with ID: 2292
I am thread 2 and alive
Thread 1: var = 22
Created thread 3 with ID: 2728
I am thread 3 and alive
Thread 2: var = 21
Created 3 Threads....
Thread 1: var = 20
Thread 3: var = 19
Thread 2: var = 18
Thread 1: var = 17
Thread 3: var = 16
Thread 2: var = 15
Thread 1: var = 14
Thread 3: var = 13
Thread 1: var = 14
Thread 3: var = 13
Thread 2: var = 12
Thread 1: var = 11
Thread 3: var = 10
Thread 2: var = 9
Thread 1: var = 8
Thread 3: var = 7
Thread 2: var = 6
Thread 1: var = 5
Thread 3: var = 4
Thread 2: var = 3
Thread 1: var = 2
Thread 3: var = 1
I am thread 2 and I will crash now!

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2832.0x8f4]
0x0040131d in crashIfZero (num=2) at gdbtest.c:17
17                      *data=911;
(gdb) thr 1
[Switching to thread 1 (thread 2832.0x97c)]#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
(gdb) set trust-frame-pointer 1
(gdb) bt
#0  0x7c91eb94 in ntdll!LdrAccessResource () from ntdll.dll
#1  0x7c91d85c in ntdll!ZwDelayExecution () from ntdll.dll
#2  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
#3  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
Previous frame identical to this frame (corrupt stack?)
(gdb) thr 2
[Switching to thread 2 (thread 2832.0x9a8)]#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  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
#3  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
Previous frame identical to this frame (corrupt stack?)
(gdb) thr 3
[Switching to thread 3 (thread 2832.0x8f4)]#0  0x0040131d in crashIfZero 
(num=2) at gdbtest.c:17
17                      *data=911;
(gdb) bt
#0  0x0040131d in crashIfZero (num=2) at gdbtest.c:17
#1  0x00401363 in func4 (num=2) at gdbtest.c:26
#2  0x0040139b in func3 (num=2) at gdbtest.c:34
#3  0x004013c8 in func2 (num=2) at gdbtest.c:41
#4  0x004013f5 in func1 (num=2) at gdbtest.c:48
#5  0x0040136e in func4 (num=2) at gdbtest.c:27
#6  0x0040139b in func3 (num=2) at gdbtest.c:34
#7  0x004013c8 in func2 (num=2) at gdbtest.c:41
#8  0x004013f5 in func1 (num=2) at gdbtest.c:48
#9  0x00401436 in threadFunc (param=0x22ff58) at gdbtest.c:55
#10 0x7c80b50b in KERNEL32!GetModuleFileNameA () from 
/vol/c/WINDOWS/system32/kernel32.dll
#11 0x00000000 in ?? () from
(gdb) thr 4
[Switching to thread 4 (thread 2832.0xaa8)]#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  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
#3  0x7c802451 in Sleep () from /vol/c/WINDOWS/system32/kernel32.dll
Previous frame identical to this frame (corrupt stack?)
(gdb)