Messages in this thread | | | Date | Wed, 2 Mar 2011 15:50:48 +0100 | From | Tejun Heo <> | Subject | Re: [RFC] Proposal for ptrace improvements |
| |
Hello,
On Wed, Mar 02, 2011 at 12:32:36PM +0100, Indan Zupancic wrote: > What might happen is that, because the current code handles the traced > task as stopped, the new SIGSTOP signal is first added and then cleared > when the task continues. This doesn't explain the double SIGSTOP > notifications, I'd expect it to either loop indefinitely or to not > notify the SIGSTOP twice.
That happens with any stopping signals. They're two different notifications for two different events. Please read the original thread referenced in the RFC for details.
> "When waitpid indicates stop on a *stop* signal, then it may be either: > * a signal delivery (strace will inject this signal with PTRACE_SYSCALL(sig)); > * or it may be a stop notification, in which case strace *must not* > try to inject this signal (this would be a bug, it'd make task running). > Instead, strace should just go back to waiting in waitpid(). > > These two possibilities can be distinquished by querying > PTRACE_GETSIGINFO. On stop notifications, PTRACE_GETSIGINFO > errors out - stop notification is not a signal delivery > and therefore it has no siginfo." > > End quote. > > You don't get the second case when not setting the WUNTRACED flag.
WUNTRACED is ignored while ptracing.
> > Again, not following. In the proposal, job control and ptrace operate > > independently, so on that we seem to agree, but I can't understand > > where the STOP signal for the parent comes from? What are you > > referring to? > > What I mean is, if you have a parent P with a child C, and C is ptraced by T, > P shouldn't get SIGSTOP notifications when it waits for C with WUNTRACED set > and C is stopped because of a ptrace event.
Yeah, sure, what I'm confused about is why you're bringing that up. Nothing changes anything related to that. There's no reason to bring it up. Am I missing something?
Thanks.
-- tejun
| |