strace, holding sigacts lock over postsig(), et al.

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research


_______________________________________________
freebsd-current at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"