This is the mail archive of the
mailing list for the GDB project.
Linux threads incorrectly "detected" in non-threaded program
- From: "Warner, William (Bill)" <wwarner at ciena dot com>
- To: "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>
- Date: Fri, 25 Jan 2002 18:09:28 -0800
- Subject: Linux threads incorrectly "detected" in non-threaded program
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.)
1. Why does gdb think there's a new thread? Does it, or libthread_db, still
the stack pointer to identify threads? What state is being relied on?
2. Can GDB be configured (at run-time or compile-time) to disable thread
not call the lin-lwp or thread_db stuff? That is, be forced to treat the
I should note that the program, when compiled for Solaris, can be
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
// process resumes, and starts creating user-level threads and context
// Then I hit Control-C.
[New Cannot find thread 2049: invalid thread handle
(gdb) info threads
1 Thread 1024 (LWP 13719) Couldn't get registers: No such process.
Couldn't get registers: No such process.
Bill Warner CIENA Core Switching Division 408 366-3385