This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: Multithreaded remote debug question
- From: imburton at micron dot com
- To: <drow at mvista dot com>
- Cc: <gdb at sources dot redhat dot com>
- Date: Tue, 17 Jun 2003 17:36:43 -0600
- Subject: RE: Multithreaded remote debug question
Daniel,
My case that crashes is too complex to send, but I
built a much smaller case the exhibits some of the same
problems.
Here is the source:
#include <pthread.h>
#include <unistd.h>
void* TH(void*);
int main()
{
pthread_t tid;
int ret;
ret = pthread_create(&tid, NULL, TH, NULL);
for (int i=0; i < 1000; i++)
{
usleep(10000);
}
}
void *TH(void* nothing)
{
int i=100;
while( i)
{
i--;
}
return 0;
}
When I run, I set a breakpoint on line 21, the
while(i) loop in TH(). I step past it and I get a
SIGTRAP in the main thread. I switch back to the second
thread and step again, and I get another SIGTRAP. I go
back to the second thread, and step once more and the
application doesn't come back. In my real application
I get a SIGSEGV at this point instead of hanging.
Here is the host gdb output:
GNU gdb 5.3.0.90_20030612
Copyright 2002 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 "i386-pc-linux-gnu".
(gdb) file GdbTest
Reading symbols from GdbTest...done.
(gdb) target remote 137.201.70.15:7000
Remote debugging using 137.201.70.15:7000
0x40000a50 in ?? ()
(gdb) break GdbTest.cpp:21
Breakpoint 1 at 0x8048455: file GdbTest.cpp, line 21.
(gdb) c
Continuing.
[New Thread 16384]
[New Thread 16386]
[Switching to Thread 16386]
Breakpoint 1, TH(void*) (nothing=0x0) at GdbTest.cpp:21
21 while( i)
(gdb) info threads
3 Thread 32769 0x4020fb11 in poll () from /lib/libc.so.6
* 2 Thread 16386 TH(void*) (nothing=0x0) at GdbTest.cpp:21
1 Thread 16384 0x401e6816 in nanosleep () from /lib/libc.so.6
(gdb) s
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 16384]
0x401e6818 in nanosleep () from /lib/libc.so.6
(gdb) info threads
3 Thread 32769 0x4020fb11 in poll () from /lib/libc.so.6
2 Thread 16386 0x08048456 in TH(void*) (nothing=0x0) at GdbTest.cpp:21
* 1 Thread 16384 0x401e6818 in nanosleep () from /lib/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 16386)]#0 0x08048456 in TH(void*) (nothing=0x0)
at GdbTest.cpp:21
21 while( i)
(gdb) s
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 16384]
0x401e681b in nanosleep () from /lib/libc.so.6
(gdb) info threads
3 Thread 32769 0x4020fb11 in poll () from /lib/libc.so.6
2 Thread 16386 0x08048456 in TH(void*) (nothing=0x0) at GdbTest.cpp:21
* 1 Thread 16384 0x401e681b in nanosleep () from /lib/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 16386)]#0 0x08048456 in TH(void*) (nothing=0x0)
at GdbTest.cpp:21
21 while( i)
(gdb) s
-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com]
Sent: Tuesday, June 17, 2003 3:56 PM
To: imburton
Cc: gdb@sources.redhat.com
Subject: Re: Multithreaded remote debug question
On Tue, Jun 17, 2003 at 03:52:44PM -0600, imburton@micron.com wrote:
> Hi, (My second attempt, the first one was horribly spaced)
Still got your margins a bit wide.
> I have been unsuccessful in consistently remote debugging a multithreaded Linux application,
> and I am looking for advice. I am using gdb 5.3 (with patches for supporting glib 2.3) on both the host
> and target systems. I am not having troubles when debugging locally with gdb, only with gdbserver.
> The majority of problems occur when trying to step or next after a breakpoint from within a thread, I
> either get an unexpected SIGSEGV or a SIGTRAP in usleep().
>
> Looking through this mailing list, and I see others have had problems quite similar to mine. Does anyone
> have advice?
>
> Looking at this, http://sources.redhat.com/ml/gdb/2003-04/msg00068.html, message,
> fixing this problem requires a change to the gdbserver protocol. Is there a patch planned for this?
> If not, will it be addressed in version 6.
There's no way to tell from this if you're talking about the right
problem. Can you make a small test case which shows the problem, and
show us the commands you gave?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer