utrace-ptrace && detach with signal semantics

[Jan Kratochvil]

On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
> Currently, if a tracer does ptrace(DETACH, tracee, SIGXXX)
> and then another/same tracer does ptrace(ATTACH, tracee)
> then SIGXXX will not be reported to the new tracer.
> 
> Why?

Naive programs expect the first signal after PTRACE_ATTACH will be SIGSTOP.


> It is not trivial to implement, and I don't understand why
> it is important to keep this behaviour. But we have the test
> case which checks this: attach-into-signal.

This testcase is in fact PASSing even when non-SIGSTOP signal is sent as the
first one after PTRACE_ATTACH.  It has specific handling of such cases.

If it is the official goal we probably do not have a testcase for it.
AI: Approved to modify attach-into-signal to check it does not happen?


> Could you explain what can be breaked if SIGXXX will be reported
> to the next tracer (assuming the 2nd ATTACH is fast enough) ?

With a testcase looping in: void handler(int sig) { raise(sig); }:
the latest official GDB release (6.8) will:

Attaching to process 5412
linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid == GET_PID
(inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y


If they do not assertion check they will at least lose the pending signal
after the attach/detach pair.


> I do not think there is a "real life" application that does
> ATTACH + DETACH and relies on fact it must not see this sig.

I think FSF GDB is enough, isn't it?


Thanks,
Jan