From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 834 invoked by alias); 15 Apr 2008 01:49:29 -0000 Received: (qmail 735 invoked by uid 22791); 15 Apr 2008 01:49:27 -0000 X-Spam-Check-By: sourceware.org Received: from qmta06.emeryville.ca.mail.comcast.net (HELO QMTA06.emeryville.ca.mail.comcast.net) (76.96.30.56) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Apr 2008 01:49:06 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Db9b1Z00317UAYkA60Ea00; Tue, 15 Apr 2008 01:47:47 +0000 Received: from gateway.sf.frob.com ([76.102.158.52]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id Ddp21Z00F18718U8Z00000; Tue, 15 Apr 2008 01:49:03 +0000 X-Authority-Analysis: v=1.0 c=1 a=Mp8WEBwWbE8A:10 a=EkON7fw8eWMA:10 a=RYFLW6ebtpNBegQnzZ7X4w==:17 a=Ko9_Rz86JaRCvW4QETEA:9 a=pZm2IyY2AjxeOCquLtEr98UONgUA:4 a=MxZ3bB5I4kYA:10 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 93AF4357B; Mon, 14 Apr 2008 18:26:33 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 6573626FA5F; Mon, 14 Apr 2008 18:26:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz X-Fcc: ~/Mail/linus Cc: Jan Kratochvil , Doug Evans , GDB Patches , mark.kettenis@xs4all.nl Subject: Re: [patch] Fix Linux attach to signalled/stopped processes In-Reply-To: Daniel Jacobowitz's message of Monday, 14 April 2008 10:34:48 -0400 <20080414143448.GA32227@caradoc.them.org> 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> <20080414143448.GA32227@caradoc.them.org> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. Message-Id: <20080415012633.6573626FA5F@magilla.localdomain> Date: Tue, 15 Apr 2008 08:14:00 -0000 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/msg00269.txt.bz2 > Isn't this still racy? [...] Yes, you're right. > This has the same problem of using SIGSTOP in that it may stop other > threads of the process. No, it won't. Generating SIGSTOP doesn't stop anything (it only clears all pending SIGCONTs--unlike generating SIGCONT, which does the resuming). Things only stop when SIGSTOP is delivered. When you use tkill or PTRACE_ATTACH to send the SIGSTOP to the particular thread, it is already ptrace'd by the time it tries to deliver the signal, so you intercept it. The only way other threads can be stopped is if you do PTRACE_CONT,SIGSTOP or similar. > 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. The significance of SIGSTOP is that it cannot be blocked (and that it's what PTRACE_ATTACH generates anyway). For the thread "to be signalled", you have to generate some signal that is not blocked by that thread. Every other signal can be blocked, except for SIGKILL (which is too significant in its own right). > Since each SIGSTOP we send stops the whole group, [...] This is not so in the contexts I think you mean, as I described above. > 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. In practice you will 99.44% of the time be able to find some RT signal that is not blocked. But to worry about the 0.66% you still have to fall back to SIGSTOP, and in that case you can't rely on queuing. Thanks, Roland