From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1919 invoked by alias); 20 Sep 2010 21:20:45 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 1908 invoked by uid 22791); 20 Sep 2010 21:20:44 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Mon, 20 Sep 2010 21:20:00 -0000 From: Oleg Nesterov To: archer@sourceware.org Subject: [BUG] gdb: quit hangs after step into signal handler Message-ID: <20100920211715.GA10574@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00205.txt.bz2 In short, gdb uses ptrace(PTRACE_KILL) + wait() to detach/kill the tracee. Well, I think PTRACE_KILL should be avoided but this is offtopic, ptrace(PTRACE_CONT, SIGKILL) has the same problem if the tracee has stepped into the signal handler. $ gdb /usr/bin/perl GNU gdb (GDB) 7.1 ... (gdb) (gdb) set args -e '$SIG{HUP}=sub{}; kill HUP, $$; 1 while 1' (this sets a signal handler for SIGHUP, sends SIGHUP to itself, then spins forever) (gdb) r Starting program: /usr/bin/perl -e '$SIG{HUP}=sub{}; kill HUP, $$; 1 while 1' [Thread debugging using libthread_db enabled] Program received signal SIGHUP, Hangup. 0x000000375fa32507 in kill () from /lib64/libc.so.6 (gdb) si 0x00000037522a2a40 in Perl_csighandler () from /usr/lib64/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so (step into handler) (gdb) q A debugging session is active. Inferior 1 [process 9694] will be killed. Quit anyway? (y or n) y (ptrace(PTRACE_KILL) + wait) Hangs "forever" in wait4(). At first I thought this is another bug in ptrace-utrace (and I even started doing the patch), but then I recalled that this is what upstream does, and ptrace-utrace just tries to be compatible. There is no signal context after step-into-handler, ptrace(PTRACE_KILL) or ptrace(PTRACE_CONT, SIGKILL) acts like ptrace(CONT, pid, 0,0) and just resumes the tracee. Probably gdb should just do kill(tracee, SIGKILL) when it wants to terminate the tracee. Oleg.