From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32263 invoked by alias); 26 May 2015 10:26:14 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 32231 invoked by uid 48); 26 May 2015 10:26:14 -0000 From: "palves at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug python/14382] gdb hangs after plotting with matplotlib Date: Tue, 26 May 2015 10:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: python X-Bugzilla-Version: 7.4 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: palves at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q2/txt/msg00322.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=14382 --- Comment #16 from Pedro Alves --- 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.