From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 16:13:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 351D816A4CE; Thu, 8 Jan 2004 16:13:48 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E81543D31; Thu, 8 Jan 2004 16:13:46 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i090CKUd024413; Thu, 8 Jan 2004 19:12:20 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i090CJa0024410; Thu, 8 Jan 2004 19:12:19 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 8 Jan 2004 19:12:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Lewis In-Reply-To: <200401081210.i08CAt7E019668@gw.catspoiler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: strace, holding sigacts lock over postsig(), et al. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Watson List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 00:13:48 -0000 On Thu, 8 Jan 2004, Don Lewis wrote: > In both issignal() and postsig() I think it would be safe to drop the > p_sig mutex before _STOPEVENT() and grab the mutex again afterwards. > About the only thing that can happen during the interim would be the > receipt of another signal and I don't think that would be a problem. > Dropping the mutex is how issignal() handles ptracestop() a bit further > down in the code. Alright, a headache or so later, here are my conclusions: (1) I committed the change to drop the sigact mutex around the two calls to stopevent(). I agree it should be safe. (2) Ctrl-T gives some mighty useless output if the thread selected for siginfo() is suspended or in another less common state, so I modified siginfo() some to be more informative. As a couple of people have pointed out, "You should never get the intrwait case" -- yeah, I know. But if I do get it, I want to know about it. (3) There appears to be a problem associated with procfs waiting for a process being debugged to suspend. When strace calls PIOCWAIT using procfs, the debugging proces performs an msleep() on p_stype. However, the child process appears already to be suspended in thread_suspend_check() due to TDS_INHIBITED resulting from P_STOPPED being set. I think this may be a property of conflicting suspension models: stopevent() and the scheduler suspended state. This may be a result of strace using both ptrace() and procfs side-by-side. In any case, the parent strace process will wait forever for the child to hit a stopevent, which the child will never hit. I'm still attempting to wade through the more complex thread/process state machine with KSE and figure out what should be happening. I also need to grab a ktrace of strace doing its thing to figure out what precise sequence of events is kicking off the problem: for example, it could be that the debugging attachment is being done using ptrace(), but strce is then trying to use procfs to wait for events. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research