Linux threads incorrectly "detected" in non-threaded program

Linux threads incorrectly "detected" in non-threaded program

[Warner, William (Bill)]

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
exists.) 
However, the program does do its own user-level context switching
(save/restore 
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?
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
program
as non-threaded?

   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
Continuing.
     // process resumes, and starts creating user-level threads and context
switching.
     // 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.
(gdb) c
Continuing.
Couldn't get registers: No such process.
(gdb)

Thanks,
--
Bill Warner     CIENA Core Switching Division      408 366-3385

Re: Linux threads incorrectly "detected" in non-threaded program

[Daniel Jacobowitz]

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
> exists.) 
> However, the program does do its own user-level context switching
> (save/restore 
> 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
> program
> 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
> Continuing.
>      // process resumes, and starts creating user-level threads and context
> switching.
>      // 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