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

[Daniel Jacobowitz <drow at mvista dot 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
> 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