This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb stack trace problems
- From: Roland Schwingel <roland dot schwingel at onevision dot de>
- To: gdb <gdb at sources dot redhat dot com>, Daniel Jacobowitz <drow at false dot org>
- Date: Mon, 18 Apr 2005 15:47:02 +0200
- Subject: Re: gdb stack trace problems
Hi Daniel and List,
Thanks for your response.
Daniel Jacobowitz wrote on 16.04.2005 16:09:50:
> On Fri, Apr 15, 2005 at 05:06:05PM +0200, Roland Schwingel wrote:
> > Hi....
> >
> > At present we are suffering from stack trace problems with recent
> > versions of gdb.
> > I desperately hope someone knows a reason for it and can help.
> >
> > But from the beginning:
> > We are using gdb on cygwin to debug mingw programs. GDB works well but
> > in recent
> > version (starting with 6.x) it cannot produce correct stack dumps
> > anymore when something
> > has crashed. Our applications are multithreaded.
> >
> > In the past we used 5.3 which worked much better in that case but had
> > other problems.
> > We switched a while ago to 6.2 and then to 6.2.1 and today I compiled
> > 6.3.50 from CVS.
> > And it is all the same... When I get a crash I just get corrupted
stacks
> > telling nothing useful.
> >
> > Does anyone know what is the reason for this and how to fix it?
>
> Sorry, but you haven't given us any information to answer your question
> with. Test case? Compiler version? Example?
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...
So here are the infos....
I am running gcc-3.2.2 on cygwin. The binaries to debug are
compiled for mingw.
I have attached a small example with output from gdb 6.3.50 and 5.3
to see what I mean. It is a pretty simple example. It is a small hack
generating 3 additional threads. Each thread decrements after some
sleeping a global variable. When the variable reaches 0 the thread
who did the last decrement generates a segmentation violation
to crash. With this synthetic example I can get the resulting
stack trace of the crashing thread with both versions of gdb,
but with 6.x gdbs I can no longer get the stack dumps of the
other threads. In real life when generating threads from
threads from threads I most of the time did not get any
good stack dump of the crashing thread at all with 6.x
gdbs, which is really a kille. With 5.3 I can get good
stack dumps. I will try to improve my example to
also show what I mean.
With this example you see the difference in output of gdb 5.3 and 6.2.
Any clues why the output of gdb 6.x is IMHO much bader
compared to the 5.3 output?
Example:
============================================================
#include <stdio.h>
#include <windows.h>
void func1(int num);
int var = 23;
void crashIfZero(int num)
{
var--;
if (var == 0)
{
int *data=0x0;
printf ("I am thread %d and I will crash now!\n",num);
*data=911;
}
else
printf ("Thread %d: var = %d\n",num,var);
}
void func4(int num)
{
Sleep(100);
crashIfZero(num);
func1(num);
}
void func3(int num)
{
Sleep(100);
crashIfZero(num);
func4(num);
}
void func2(int num)
{
Sleep(100);
crashIfZero(num);
func3(num);
}
void func1(int num)
{
Sleep(100);
crashIfZero(num);
func2(num);
}
DWORD WINAPI threadFunc(LPVOID param)
{
int num = *(DWORD *)param;
printf ("I am thread %d and alive\n");
func1(num);
}
void makeThreads(int num)
{
int i;
for (i=1;i<=num;i++)
{
HANDLE threadHandle;
DWORD threadId, threadParam = i;
threadHandle =
CreateThread(NULL,0,threadFunc,&threadParam,0,&threadId);
if (threadHandle == NULL)
printf ("Couldn't create thread %d\n",i);
else
printf ("Created thread %d with ID: %d\n",i,threadId);
Sleep(50);
}
printf ("Created %d Threads....\n",num);
Sleep(200000);
}
int main(int argc,char **argv)
{
setbuf(stdout,NULL);
setbuf(stderr,NULL);
printf ("test gdb stack tracing during a crash\n");
makeThreads(3);
}
============================================================
Compiled with:
$ gcc -g -mno-cygwin gdbtest.c -o gdbtest
Debugging session with 6.3.50:
=====================
$ gdb.exe ./gdbtest.exe
GNU gdb 6.3.50.20050415-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: 2984
I am thread 1 and alive
Created thread 2 with ID: 3980
I am thread 2 and alive
Thread 1: var = 22
Created thread 3 with ID: 3764
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 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 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
(gdb) thr 2
[Switching to thread 2 (thread 2316.0xba8)]#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) thr 3
[Switching to thread 3 (thread 2316.0xf8c)]#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 0x0022ff58 in ?? ()
#12 0x0022fc40 in ?? ()
#13 0x77bfe524 in msvcrt!_get_osfhandle ()
#14 0x0022ff58 in ?? ()
#15 0x7ffdd000 in ?? ()
#16 0x867c0600 in ?? ()
#17 0x008bffc0 in ?? ()
#18 0x8601ee40 in ?? ()
#19 0xffffffff in ?? ()
#20 0x7c8399f3 in KERNEL32!FindAtomW () from
/vol/c/WINDOWS/system32/kernel32.dll
#21 0x7c80b518 in KERNEL32!GetModuleFileNameA () from
/vol/c/WINDOWS/system32/kernel32.dll
#22 0x00000000 in ?? () from
(gdb) thr 4
[Switching to thread 4 (thread 2316.0xeb4)]#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
Debugging with gdb 5.3:
=================
$ gdb53 ./gdbtest.exe
GNU gdb 5.3 2003-03-03-cvs
Copyright 2003 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
(gdb) r
Starting program: /tmp/gdbtest.exe
test gdb stack tracing during a crash
Created thread 1 with ID: 3580
I am thread 1 and alive
Created thread 2 with ID: 3320
I am thread 2 and alive
Thread 1: var = 22
Created thread 3 with ID: 4068
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 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 604.0xcf8]
0x0040131d in crashIfZero (num=2) at gdbtest.c:17
17 *data=911;
(gdb) thr 1
[Switching to thread 1 (thread 604.0xd2c)]#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 0x0040156c in makeThreads (num=3) at gdbtest.c:77
#4 0x0040161d in main (argc=1, argv=0x3d4068) at gdbtest.c:86
(gdb) thr 2
[Switching to thread 2 (thread 604.0xdfc)]#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 0x004013dc in func1 (num=1) at gdbtest.c:46
#4 0x0040136e in func4 (num=1) at gdbtest.c:27
#5 0x0040139b in func3 (num=1) at gdbtest.c:34
#6 0x004013c8 in func2 (num=1) at gdbtest.c:41
#7 0x004013f5 in func1 (num=1) at gdbtest.c:48
#8 0x0040136e in func4 (num=1) at gdbtest.c:27
#9 0x0040139b in func3 (num=1) at gdbtest.c:34
#10 0x004013c8 in func2 (num=1) at gdbtest.c:41
#11 0x004013f5 in func1 (num=1) at gdbtest.c:48
#12 0x00401436 in threadFunc (param=0x22ff58) at gdbtest.c:55
#13 0x7c80b50b in KERNEL32!GetModuleFileNameA () from
/vol/c/WINDOWS/system32/kernel32.dll
(gdb) thr 3
[Switching to thread 3 (thread 604.0xcf8)]#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
(gdb) thr 4
[Switching to thread 4 (thread 604.0xfe4)]#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 0x00401355 in func4 (num=3) at gdbtest.c:25
#4 0x0040139b in func3 (num=3) at gdbtest.c:34
#5 0x004013c8 in func2 (num=3) at gdbtest.c:41
#6 0x004013f5 in func1 (num=3) at gdbtest.c:48
#7 0x0040136e in func4 (num=3) at gdbtest.c:27
#8 0x0040139b in func3 (num=3) at gdbtest.c:34
#9 0x004013c8 in func2 (num=3) at gdbtest.c:41
#10 0x004013f5 in func1 (num=3) at gdbtest.c:48
#11 0x00401436 in threadFunc (param=0x22ff58) at gdbtest.c:55
#12 0x7c80b50b in KERNEL32!GetModuleFileNameA () from
/vol/c/WINDOWS/system32/kernel32.dll
As you might see the stack trace for threads 1,2 and 4 are quite
unusable in gdb 6.3.50 whereas they are
correct in 5.3. Any clues to get them ok in 6.x?
Regards,
Roland