PT_ATTACH resumes suspended process

[Ben Widawsky]

> Looking at the sendsig label in sys_process.c:kern_ptrace() makes it clear
> what's happening - in your testing the process was already stopped so
> the code sets td_xsig to SIGSTOP and wakes it up to send it the signal.
>
> But td_xsig doesn't seem to be used anywhere to set pending signals.  Maybe
> I missed the place where that happens.
>
> The assumption seems to be that a process being traced will only be
> stopped if the debugger is already attached and that any signals being
> sent to it are coming from the debugger itself.
>
> This assumption is wrong if the process being attached to was already
> stopped.
>
> It seems to me that checking for req == PT_ATTACH when the process is
> already stopped and doing a break; in that case might be a solution.

Could you be more specific? It seems to me even if you had a special case in
kern_ptrace to handle PT_ATTACH when the process is suspended, the code would
end up being almost identical to ptracestop(). Unless I didn't follow you.

Because of this, I think what I suggested initially, esentially resuming the
thread with a pending SIGSTOP (by checking the value of xsig when the thread
switches back in issignal) would be a better approach. The hack I put in bothers
me a bit because some of the other threads may resume, and even run for a while,
but it's still better than the existing behavior.