Date: Thu, 8 Jan 2004 19:12:19 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: strace, holding sigacts lock over postsig(), et al. Message-ID: <Pine.NEB.3.96L.1040108180401.86188B-100000@fledge.watson.org> In-Reply-To: <200401081210.i08CAt7E019668@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040108180401.86188B-100000>