This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]