From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17203 invoked by alias); 16 Apr 2002 01:10:23 -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 17196 invoked from network); 16 Apr 2002 01:10:20 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 16 Apr 2002 01:10:20 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id SAA01568; Mon, 15 Apr 2002 18:10:13 -0700 (PDT) Message-ID: <3CBB7717.B7772E4A@redhat.com> Date: Mon, 15 Apr 2002 18:10:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Hilfinger@otisco.mckusick.com CC: gdb-patches@sources.redhat.com, hilfinger@cs.berkeley.edu Subject: Re: [RFA] lin-lwp.c change to avoid obscure hanging References: <200204121931.g3CJVae12068@reddwarf.sfbay.redhat.com> <200204130905.CAA11202@otisco.McKusick.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00547.txt.bz2 "Paul N. Hilfinger" wrote: > > 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 This isn't really a sensable thing to do anyway. Probably the user is imagining that this will cause thread B to be treated in some way specially (eg. resumed before the others), but it will not (or at least it should not). > 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. Puzzling: shouldn't "prepare_to_proceed" be handling this? In theory, before gdb actually resumes the child, it should restore the "current thread" to be thread A. > > 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)