This is the mail archive of the
mailing list for the GDB project.
Re: Linux threads incorrectly "detected" in non-threaded program
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: "Warner, William (Bill)" <wwarner at ciena dot com>
- Cc: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- Date: Sat, 26 Jan 2002 02:08:32 -0500
- Subject: Re: Linux threads incorrectly "detected" in non-threaded program
- References: <FB77A8A317F5D31199F1009027DE4A870158FFD0@wntcsdexg01.csd.ciena.com>
On Fri, Jan 25, 2002 at 06:09:28PM -0800, Warner, William (Bill) wrote:
> Hi -
> I'm using GDB 5.1.1 on Linux 2.4.7 kernel (RedHat 7.2).
> The program I'm trying to debug links against libpthread.so (indirectly),
> but does not create any additional pthreads (only the "initial" thread
> However, the program does do its own user-level context switching
> registers and change stack pointers.)
> My problem is that after the program starts up, GDB apparently
> "detects" a new thread or lwp, but of course fails when it tries to use it
> (since it doesn't really exist.)
> Two questions:
> 1. Why does gdb think there's a new thread? Does it, or libthread_db, still
> rely on
> the stack pointer to identify threads? What state is being relied on?
When does it detect a new thread? When you create one, or at startup?
If the latter, then it should still work just fine. Performance will
be impacted - which is avoidable, but not currently avoided - but it
should still work.
> 2. Can GDB be configured (at run-time or compile-time) to disable thread
> awareness and
> not call the lin-lwp or thread_db stuff? That is, be forced to treat the
> as non-threaded?
I don't believe there is an option for this. There probably should be.
> I should note that the program, when compiled for Solaris, can be
> debugged fine
> with GDB 5.0. The Solaris implementation therefore seems more robust.
> Here's a transcript:
> % gdb simv
> GNU gdb 5.1.1
> (gdb) attach 12418
> Attaching to program:
> /home/wwarner/p4/hw/txn/asics/sim/tb_scm/src/i686/simv, process 13228
> Reading symbols from /lib/librt.so.1...done.
> Loaded symbols for /lib/librt.so.1
> Reading symbols from /lib/i686/libpthread.so.0...done.
> [New Thread 1024 (LWP 13228)]
> Loaded symbols for /lib/i686/libpthread.so.0
> 0x4019ca31 in __libc_nanosleep () from /lib/i686/libc.so.6
> (gdb) continue
> // process resumes, and starts creating user-level threads and context
> // Then I hit Control-C.
> [New Cannot find thread 2049: invalid thread handle
This line above is quite peculiar. Is the source to your application
available, or can you create a reduced testcase, perhaps? I'd quite
like to see what's going wrong.
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer