Re: gdb and multi-threaded applications.

[Michael Snyder <msnyder@cygnus.com>]

Kevin Buettner wrote:
>
> On Mar 10,  1:03pm, jjs wrote:
>
> > Sorry I have not been back to you sooner, I have been distracted by other
> > things. I tried getting a test application to exhibit the same behaviour
> > with no luck. However, I did notice that before the call to pthread_create
> > to start up the new thread we have the line:
> >
> >     pthread_sigmask(SIG_BLOCK, &fullSigMask, &sigMask);
> >
> > All the bits in fullSigMask are set, so this call blocks all signals to the
> > calling thread. Commenting this line out makes everything work under gdb,
> > the new thread gets created and doing 'info threads' after this gives me a
> > list of all the threads running in the process. This implies that gdb
> > requires a signal to be unblocked at the point the thread is created. If
> > this is fact the case, which signal must we not block in order for correct
> > operation under gdb?
>
> SIGCHLD.
>
> (I think.)
>
> Background for Michael: Jerry reported a problem in which gdb (on
> linux/ppc) hangs on a pthread_create().   Jerry has verified that
> the thread tests in the test suite work properly on his platform,
> so we know that gdb does work (some of the time) when creating
> new threads.  Jerry's application is proprietary and I've asked him
> to try to distill the problem into a small example that we can test.
>
> Note to Jerry: I'd still like a small example, preferably one that
> we could eventually put into the testsuite.
>
> Kevin

Afterthought -- GDB also uses SIGSTOP to stop threads when
one of them hits a breakpoint etc.  You shouldn't block that.

				Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/