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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Kevin Buettner wrote:
On Mar 10, 1:03pm, jjs wrote:
quoted
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.
Your analysis is correct. The linuxthreads library uses certain
signals to communicate and synchronize between threads. GDB
listens in on these signals. Most commonly they are SIGUSR32,
SIGUSR33 and SIGUSR34, but this is not always the case. I would
think that blocking these signals might affect more than just
GDB debugging (ie. it might affect the program's behavior directly).
quoted
If
this is fact the case, which signal must we not block in order for correct
operation under gdb?
SIGCHLD.
(I think.)
SIGCHLD does come into play as well, although I have never
fully understood its role. Try unblocking SIGCHLD, but also
be prepared to try unblocking the ones I mentioned above.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Kevin Buettner wrote:
On Mar 10, 1:03pm, jjs wrote:
quoted
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/