From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21867 invoked by alias); 13 Apr 2002 09:05:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21860 invoked from network); 13 Apr 2002 09:05:28 -0000 Received: from unknown (HELO otisco.McKusick.COM) (209.31.233.190) by sources.redhat.com with SMTP; 13 Apr 2002 09:05:28 -0000 Received: (from hilfingr@localhost) by otisco.McKusick.COM (8.9.3/8.9.3) id CAA11202; Sat, 13 Apr 2002 02:05:28 -0700 Date: Sat, 13 Apr 2002 02:05:00 -0000 Message-Id: <200204130905.CAA11202@otisco.McKusick.COM> X-Authentication-Warning: localhost.localdomain: hilfingr set sender to hilfingr@otisco.mckusick.com using -f From: "Paul N. Hilfinger" To: gdb-patches@sources.redhat.com Subject: [RFA] lin-lwp.c change to avoid obscure hanging Reply-to: Hilfinger@otisco.mckusick.com References: <200204121931.g3CJVae12068@reddwarf.sfbay.redhat.com> X-SW-Source: 2002-04/txt/msg00489.txt.bz2 Under certain obscure conditions, GDB will hang when continuing a program that uses GNU/Linux LWPs. For example, one set of circumstances that were uncovered in an Ada program were: 1. A breakpoint is tripped over in thread A. 2. When all threads are stopped, it turns out that thread B != A has received a signal (specifically SIG32, which is apparently used by the thread package). This signal, furthermore, is "not of interest" to GDB (as if according to 'set handle SIG32 pass noprint nostop'). A and B here stand for integer literals, of course. 3. The user executes the commands delete thread B continue I am uncertain as to the proper fix is for this, but I have provided one possibility below (that works for us). The long ugly comment will, I hope, prompt the more experienced among you to resolve the outstanding questions. Paul Hilfinger ACT, Inc. 2002-04-10 Paul N. Hilfinger * lin-lwp.c (lin_lwp_resume): Pass unprocessed signals to the selected lwp, if GDB is not interested in them, and no specific signal is requested. Fixes regression (hanging) displayed by 9820-005__task_switch. Index: gdb/lin-lwp.c =================================================================== RCS file: /cvs/src/src/gdb/lin-lwp.c,v retrieving revision 1.34 diff -u -p -r1.34 lin-lwp.c --- gdb/lin-lwp.c 31 Mar 2002 15:10:38 -0000 1.34 +++ gdb/lin-lwp.c 13 Apr 2002 08:41:20 -0000 @@ -605,6 +605,32 @@ lin_lwp_resume (ptid_t ptid, int step, e /* Mark this LWP as resumed. */ lp->resumed = 1; + if (WIFSTOPPED (lp->status)) + { + enum target_signal stopsig + = target_signal_from_host (WSTOPSIG (lp->status)); + + /* If we have a signal GDB is not interested in, then + arrange to pass it to the process without comment. This + should be able to happen only when one changes threads + before continuing. To be conservative, we do this only + if signo is TARGET_SIGNAL_0. + FIXME: hilfinger/2002-04-10: But this means we can't + switch to this thread and clear its signal. We could try + simply not resuming when lp->status is non-zero, and + leave it to lin_lwp_wait to catch the unhandled signal, + but it will resume ONLY this thread (see Kettenis's FIXME + in lin_lwp_wait), and this is not always right. */ + + if (signo == TARGET_SIGNAL_0 + && signal_stop_state (stopsig) == 0 + && signal_print_state (stopsig) == 0 + && signal_pass_state (stopsig) == 1) + { + signo = stopsig; + lp->status = 0; + } + } /* If we have a pending wait status for this thread, there is no point in resuming the process. */ if (lp->status)