Re: gdb stack trace problems (Addendum)

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

Hi Mark...

Have you already had some time to look into my results with your patch to
the i386 stack unwinder? At basically it could work but obviously it
is not advancing to the next stack frame... Attached you will find my 
results
I posted to the list last week.

Thanks for your help,

Roland

----- Forwarded by Roland Schwingel/Onevision on 02.05.2005 08:59 -----

gdb-owner@sources.redhat.com wrote on 26.04.2005 11:16:03:

 > 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)
 >