[Bug python/14382] gdb hangs after plotting with matplotlib

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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.