Re: [RFC] Proposal for ptrace improvements

[Tejun Heo <tj@kernel.org>]

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