> 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.Received on Tue May 11 2010 - 01:07:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC