Re: PT_ATTACH resumes suspended process
- From: Ben Widawsky <widawsky@xxxxxxxxx>
- Date: Mon, 10 May 2010 20:07:27 -0700
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
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.
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Panic @r207844; current process: flowcleaner "Fatal trap 12: page fault while in kernel mode"
- Next by Date: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
- Previous by thread: Re: PT_ATTACH resumes suspended process
- Next by thread: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.