Re: SIGSTOP && ptrace (Was: ptrace(PTRACE_SYSCALL/CONT/DETACH, ..., SIGSTOP) does not work)

[Roland McGrath <roland@redhat.com>]

> > IOW: strace does NOT want to see this signal reported back to strace -
> > it already saw that, what's the point in seeing it again?
> 
> As I said many times, the second report is not about the signal, it
> reports that the group-stop is completed.

Oleg is correct.  The "second" report, is not "WIFSTOPPED means a ptrace
stop".  It is "WIFSTOPPED means a job control stop".  This is not meant as
a notification to tracer, but a notification to parent.  In case of
PTRACE_ATTACH, this is "unnatural" because the tracer steals the parent's
notifications, but that's just the known crime against nature that is
ptrace semantics.

> I guess, you don't like the fact that finish_stop() always clear ->exit_code
> after wake up. This is why the next ptrace(PTRACE_SYSCALL, SIGSTOP) (called
> when the tracee sleeps in finish_stop) "loses" SIGSTOP.
> 
> I can't say if this really right or not, but I guess it is too late to
> change this behaviour. I may be wrong.

I agree it's unfortunate.  But TBH it's more unfortunate that PTRACE_CONT
et al are allowed here at all.  It's a job control stop, and if the world
were right then it would only be broken by SIGCONT.  But Oleg is right,
it's too late to change it now.  Them's the semantics.

> Perhaps, you should ask how strace can distinguish between "SIGSTOP
> recieved" and "group-stop completed". I am not 100% sure, but at first
> glance this looks possible.

It is, but it's easier than the hack you suggest.  PTRACE_GETSIGINFO only
works for a ptrace stop, not a job control stop.  If wait reported SIGSTOP,
PTRACE_GETSIGINFO will fail with EINVAL for a job control stop but will
succeed for a ptrace stop.


Thanks,
Roland