Re: thirty-third thread == kaput

[Kevin Buettner <kevinb@cygnus.com>]

On Apr 17,  9:23am, Jeffrey W. Baker wrote:

> I am using gdb to debug a threaded application.  The application routinely
> spawns off a large number of threads.  My problem is that gdb does not
> seem to work with more than 32 threads:
> 
> Delayed SIGSTOP caught for LWP 16057.
> Cannot find thread 33: invalid thread handle
> (gdb) info threads
> Cannot find thread 33: invalid thread handle
> (gdb) thread 1
> [Switching to thread 1 (Thread 1024 (LWP 16025))]#0  0x4004d36a in
> __sigsuspend (
>     set=0xbffff80c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:54
> 54	../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or
> directory.
> 	in ../sysdeps/unix/sysv/linux/sigsuspend.c
> 
> This happens consistently.  I am using the 20010410 snapshot of gdb on
> Linux 2.4.3(ac7) with gcc 2.95.3 (release), binutils 2.10.1.0.4, and glibc
> 2.2.2.  I previously tried gdb 5.0, but it did not grok threads at all on
> this system: it simply stopped with "ptrace: no such process".
> 
> Is there a way to redefine the maximum number of threads when I build gdb?

There is a patch to fix this problem.  It was posted early last
October.  See...

    http://sources.redhat.com/ml/gdb-patches/2000-10/msg00014.html

Unfortunately, it no longer applies cleanly to the current sources.

I would really, really like to get this patch into the mainline
sources, but I'm quite busy at the moment and haven't been able
to find much time to work on it.

Kevin