Re: RFC: PTRACE_SEIZE needs API cleanup?

["Indan Zupancic" <indan@nul.nu>]

On Wed, September 7, 2011 04:47, Denys Vlasenko wrote:
> On Tuesday 06 September 2011 19:19, Indan Zupancic wrote:
>> >> > In case you meant that "if we request group-stop notifications by using
>> >> > __WALL | WSTOPPED, and we get group-stop notification, and we do
>> >> > PTRACE_CONT, then task does not run (it sits in group-stop until SIGCONT
>> >> > or death)", then we have a problem: gdb can't use this interface, it
>> >> > needs to be able to restart the thread (only one thread, not all of
>> >> > them, so sending SIGCONT is not ok!) from the group-stop. Yes, it's
>> >> > weird, but it's the real requirement from gdb users.
>> >> [...]
>> >> > SIGCONT's side effect of waking up from group-stop can't be blocked.
>> >> > SIGCONT always wakes up all threads in thread group.
>> >> > Using SIGCONT to control tracee will race with SIGCONTs from other
>> >> > sources.
>> >> >
>> >> > This makes SIGCONT a too coarse instrument for the job.
>> >> [...]
>> >> > Yes... until gdb will want to give user a choice after SIGSTOP: continue
>> >> > to sit in group-stop until SIGCONT (wasn't possible until
>> >> > PTRACE_LISTEN), or continue executing (gdb's current behavior if user
>> >> > uses "continue" command). Therefore, gdb needs a way to do both.
>> >>
>> >> Having thought a bit more about this, I think this is less of a problem
>> >> than it seems, because for a group stop we get a ptrace event for each
>> >> task, and this should be true for SIGCONT as well. So gdb could also
>> >> always let the group stop happen, and only when prompted to do so by
>> >> a user, continue one thread by sending SIGCONT and letting all the other
>> >> threads hang in trapped state.
>> >
>> > Won't work. SIGCONT unpauses all threads in the thread group,
>> > and _then_ it is delivered to one of the threads.
>>
>> No, it is delivered to _all_ threads.
>
> Wrong.

Argh, indeed! I always confused the SIGSTOP after fork/clone with the SIGSTOP
I sent, thinking the SIGSTOP was sent to all tasks.

Well, so much for that idea then.

>> With current ptrace you never see a SIGCONT
>
> Wrong. Even rather old strace 4.5.9 does show it.

I meant a resuming SIGCONT, not just any SIGCONT. But that a normal SIGCONT isn't
seen by all threads should have been a hint for me that perhaps the same isn't true
for SIGSTOPs, and that perhaps I should take a better look instead of repeating the
same test and mistake.

>> Not doing PTRACE_CONT will keep the thread hanging in trapped state.
>> All threads get a SIGCONT, not only one, so you can pause all threads
>> this way.
>
> As I said, you are wrong about SIGCONT.

Indeed, I was wrong.

Greetings,

Indan