This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug python/14382] gdb hangs after plotting with matplotlib
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 26 May 2015 04:56:12 +0000
- Subject: [Bug python/14382] gdb hangs after plotting with matplotlib
- Auto-submitted: auto-generated
- References: <bug-14382-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14382
--- Comment #16 from Pedro Alves <palves at redhat dot com> ---
Created attachment 8333
--> https://sourceware.org/bugzilla/attachment.cgi?id=8333&action=edit
make linux-nat.c use signalfd
I tried making linux-nat.c use signalfd now. Unless I missed something, it
doesn't seem to actually work for protecting against a library stealing
SIGCHLDs though, so it ends up useless. :-/
See the #if 0 in the patch:
~~~
#if 0
/* Hmm, if we don't do this, then gdb hangs in wait_for_sigchld.
That seems to mean that if a SIGCHLD signal handler is
called, then the signalfd file ends up with nothing to read,
and thus 'select' blocks forever. Test with:
"gdb PROGRAM -ex "maint set target-async off" -ex "set debug lin-lwp
1"
Which renders this approach worthless to protect against a
library GDB links against from stealing out SIGCHLD
handler... :-/
*/
~~~~~~~~~~~~~~~~~~
If I leave that on, things work, but if I disable it, I get:
~~~
$ gdb ~/gdb/tests/threads -ex "maint set target-async off" -ex "set debug
lin-lwp 1"
(gdb) start
(...)
LLW: exit
LLR: Preparing to resume process 15243, 0, inferior_ptid process 15243
LLR: PTRACE_CONT process 15243, 0 (resume event thread)
linux_nat_wait: [process 15243], []
LLW: enter
LNW: waitpid(-1, ...) returned 0, No child processes
LNW: about to sigsuspend
sigchld
^C^C^C^C^C^C^C^C *gdb hang*
~~~
Adding more logging in wait_for_sigchld, I could observe that
sometimes, the select returns 1, and then the read fails with EAGAIN.
Thinking that perhaps treating that as "got SIGCHLD, but some handler
consumed it" makes a "(gdb) start" sometimes work, but not always... It
seems that the select only wakes up / returns 1 if the signal arrives
while gdb is already blocked inside select. If the signal arrives and
is handled before gdb reaches select, then select hangs forever. This
kind of makes sense if the signalfd's "data" is generated on the fly
from the pending signals, not really queued in the kernel, which it is
probably how this works on the kernel side...
--
You are receiving this mail because:
You are on the CC list for the bug.