Re: [patch] Fix Linux attach to signalled/stopped processes

[Roland McGrath <roland at redhat dot com>]

> Isn't this still racy?  [...]

Yes, you're right.

> This has the same problem of using SIGSTOP in that it may stop other
> threads of the process.  

No, it won't.  Generating SIGSTOP doesn't stop anything (it only clears all
pending SIGCONTs--unlike generating SIGCONT, which does the resuming).
Things only stop when SIGSTOP is delivered.  When you use tkill or
PTRACE_ATTACH to send the SIGSTOP to the particular thread, it is already
ptrace'd by the time it tries to deliver the signal, so you intercept it.
The only way other threads can be stopped is if you do PTRACE_CONT,SIGSTOP
or similar.

> Thanks again for the assistance.  This conversation gave me a useful
> insight into one of those things you already probably know: GDB's use
> of SIGSTOP instead of another signal is not significant.  We want the
> process to be signalled, that's all.  

The significance of SIGSTOP is that it cannot be blocked (and that it's
what PTRACE_ATTACH generates anyway).  For the thread "to be signalled",
you have to generate some signal that is not blocked by that thread.
Every other signal can be blocked, except for SIGKILL (which is too
significant in its own right).

> Since each SIGSTOP we send stops the whole group, [...]

This is not so in the contexts I think you mean, as I described above.

> I'm not going to make that change right now, but I will add some
> comments about it.  We could probably use an RT signal at each point
> we want a stop.

In practice you will 99.44% of the time be able to find some RT signal
that is not blocked.  But to worry about the 0.66% you still have to
fall back to SIGSTOP, and in that case you can't rely on queuing.


Thanks,
Roland