thirty-third thread == kaput

thirty-third thread == kaput

[Jeffrey W. Baker]

Hello friends,

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?

Regards,
Jeffrey Baker

Re: thirty-third thread == kaput

[Kevin Buettner]

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

Re: thirty-third thread == kaput

[Jeffrey W. Baker]

On Tue, 17 Apr 2001, Kevin Buettner wrote:

> 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.

I'll take a look at it tonight, after I get home.  Do you think the patch
doesn't apply because of major changes to data or algorithms, or just
because code has moved around?  The patch is enormous and hairy.  As an
outsider, I would say that the best strategy is to get the patch to where
it applies, compiles, and runs, then commit it ASAP.  That will probably
break GDB for a while, but it means that this important feature will
actually get fixed.  Otherwise, it gets easier over time to just put off
the fix because it becomes harder and harder to do.

-jwb

Re: thirty-third thread == kaput

[Kevin Buettner]

On Apr 18, 11:04am, Jeffrey W. Baker wrote:

> Do you think the patch doesn't apply because of major changes to
> data or algorithms, or just because code has moved around?  The
> patch is enormous and hairy.

Mostly due to code shifting a bit or new code being added.  There
were also rejects due to some files being obsoleted.

> As an outsider, I would say that the best strategy is to get the
> patch to where it applies, compiles, and runs, then commit it ASAP. 
> That will probably break GDB for a while, but it means that this
> important feature will actually get fixed.  Otherwise, it gets
> easier over time to just put off the fix because it becomes harder
> and harder to do.

I'm working on it again and have a patch out which should apply
cleanly.  See:

    http://sources.redhat.com/ml/gdb-patches/2001-04/msg00240.html

I'm going to be committing the patch in phases.  See the introductory
text to the patch for more details.

Kevin