From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18905 invoked by alias); 14 Apr 2008 14:35:17 -0000 Received: (qmail 18874 invoked by uid 22791); 14 Apr 2008 14:35:11 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Apr 2008 14:34:51 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 88A27983D9; Mon, 14 Apr 2008 14:34:49 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 6E1CD98119; Mon, 14 Apr 2008 14:34:49 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JlPlg-00016T-JQ; Mon, 14 Apr 2008 10:34:48 -0400 Date: Mon, 14 Apr 2008 15:09:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Jan Kratochvil , Doug Evans , GDB Patches , mark.kettenis@xs4all.nl Subject: Re: [patch] Fix Linux attach to signalled/stopped processes Message-ID: <20080414143448.GA32227@caradoc.them.org> Mail-Followup-To: Roland McGrath , Jan Kratochvil , Doug Evans , GDB Patches , mark.kettenis@xs4all.nl References: <20080401223012.GA14076@host0.dyn.jankratochvil.net> <20080410153735.GD21662@caradoc.them.org> <20080410154839.GA5375@host0.dyn.jankratochvil.net> <20080410231205.2DBFD26F992@magilla.localdomain> <20080411161824.GA4183@host0.dyn.jankratochvil.net> <20080412000155.7F07A26FA5E@magilla.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080412000155.7F07A26FA5E@magilla.localdomain> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00241.txt.bz2 On Fri, Apr 11, 2008 at 05:01:55PM -0700, Roland McGrath wrote: > Ah, right. You can also do: > > PTRACE_ATTACH -> pending SIGSTOP > ... if running -> stopped, no pending SIGSTOP > ... if stopped -> still stopped, pending SIGSTOP > tkill (SIGSTOP, tid) -> pending SIGSTOP > > PTRACE_CONT, tid, 0 -> if not stopped the first time yet, ESRCH > -> if stopped, wakes up, dequeues SIGSTOP > wait -> always see it stop > > You just don't know whether you'll see one more spurious SIGSTOP or not. > (Once you've waited, you can synchronously check /proc, but that doesn't > tell you whether it was your spurious one or just an outside one sent > right now.) Isn't this still racy? SIGCONT wakeups happen synchronously, but SIGSTOP stops do not. After the PTRACE_ATTACH the thread might be running with a pending SIGSTOP. Then the tkill has no effect, and if the thread stops between the tkill and the PTRACE_CONT it will have no reason to stop again. Fixing the race is not hard though: grub around in /proc for status. First PTRACE_ATTACH, which sends a SIGSTOP. Then check /proc. If it is running, it must have a pending SIGSTOP; we can wait for it so skip the tkill and the PTRACE_CONT. If it is not running, it may or may not have a pending SIGSTOP. So do as you described above with tkill and PTRACE_CONT. This has the same problem of using SIGSTOP in that it may stop other threads of the process. But it avoids using SIGCONT, so it will not wake up other threads of the process. For GDB's purposes, that is currently good enough - strictly better than before, while the SIGCONT approach could cause other threads to run before we attached to them. Thanks again for the assistance. This conversation gave me a useful insight into one of those things you already probably know: GDB's use of SIGSTOP instead of another signal is not significant. We want the process to be signalled, that's all. Since each SIGSTOP we send stops the whole group, I suspect if I checked using PTRACE_GETSIGINFO I would find most of the threads in finish_stop and not fully ptrace controllable. To preserve our last vestiges of LinuxThreads support we have to continue sending SIGSTOP once per thread, or else use a different signal. I'm not going to make that change right now, but I will add some comments about it. We could probably use an RT signal at each point we want a stop. -- Daniel Jacobowitz CodeSourcery