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 ResearchReceived on Thu Jan 08 2004 - 15:13:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:37 UTC