From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7663 invoked by alias); 19 Apr 2002 18:53:30 -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 7628 invoked from network); 19 Apr 2002 18:53:27 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 19 Apr 2002 18:53:27 -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 LAA03294; Fri, 19 Apr 2002 11:53:21 -0700 (PDT) Message-ID: <3CC064E4.55E3C68C@redhat.com> Date: Fri, 19 Apr 2002 11:53: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 Subject: Re: [RFA] lin-lwp.c change to avoid obscure hanging References: <200204121931.g3CJVae12068@reddwarf.sfbay.redhat.com> <200204130905.CAA11202@otisco.McKusick.COM> <3CBB7717.B7772E4A@redhat.com> <200204170952.CAA17455@otisco.McKusick.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00631.txt.bz2 "Paul N. Hilfinger" wrote: > > > > 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. There are actually three predicates here: - what is supposed to happen - what does happen - what is expected to happen. What you describe above (thread 7 receives the signal) is what is expected to happen. GDB's thread model is lacking in several areas, and one of them is the ability to resume a thread other than the one that stopped. Since we have not designed an interface for doing this in general, we don't do it at all (even on platforms such as Linux where it might be possible). So the thread that resumes is always the thread that stopped, no matter what thread you switch to in the mean time. > > 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. Ugh! Well, that's a bug. That's not what is "supposed" or "expected" to happen. > > 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. No, that's a bug too. > Question: How much of this, if any, is intentional? What should happen in > these cases? Q1 is intentional, Q2 and Q3 are not. Michael