From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13453 invoked by alias); 17 Apr 2002 09:52:44 -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 13442 invoked from network); 17 Apr 2002 09:52:42 -0000 Received: from unknown (HELO otisco.McKusick.COM) (209.31.233.190) by sources.redhat.com with SMTP; 17 Apr 2002 09:52:42 -0000 Received: (from hilfingr@localhost) by otisco.McKusick.COM (8.9.3/8.9.3) id CAA17455; Wed, 17 Apr 2002 02:52:35 -0700 Date: Wed, 17 Apr 2002 02:52:00 -0000 Message-Id: <200204170952.CAA17455@otisco.McKusick.COM> X-Authentication-Warning: localhost.localdomain: hilfingr set sender to hilfingr@otisco.mckusick.com using -f From: "Paul N. Hilfinger" To: msnyder@redhat.com CC: gdb-patches@sources.redhat.com In-reply-to: <3CBB7717.B7772E4A@redhat.com> (message from Michael Snyder on Mon, 15 Apr 2002 17:57:59 -0700) Subject: Re: [RFA] lin-lwp.c change to avoid obscure hanging Reply-to: Hilfinger@otisco.mckusick.com References: <200204121931.g3CJVae12068@reddwarf.sfbay.redhat.com> <200204130905.CAA11202@otisco.McKusick.COM> <3CBB7717.B7772E4A@redhat.com> X-SW-Source: 2002-04/txt/msg00558.txt.bz2 > > 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). Oh, I'm SO glad you brought this up, because it is a point that could stand clarification. Q1. Consider the following sequence (user input preceded by prompts) (gdb) run ... Breakpoint 1, philosopher ... (gdb) info thread * 7 Thread 5126 (runnable) ... ... (gdb) thread 6 # I.e., Some thread other than the current one (gdb) signal 1 What is supposed to happen? What DOES happen (on Linux) is that thread 7 receives SIGHUP. Q2. Now consider what happens when one thread is sent an asynchronous SIGHUP (on Linux, there are kernel threads, and you can address a signal to a specific thread from the command line with the kill command). (gdb) run ... Program received signal SIGHUP, Hangup. ... (gdb) info thread * 7 Thread 5126 (runnable) ... ... (gdb) thread 6 (gdb) cont Here what happens is that thread *6* receives SIGHUP. Q3. Finally, we have (gdb) run ... Program received signal SIGHUP, Hangup. ... (gdb) info thread * 7 Thread 5126 (runnable) ... ... (gdb) thread 6 (gdb) signal 1 Again, thread 6 receives SIGHUP. Question: How much of this, if any, is intentional? What should happen in these cases? Paul Hilfinger