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
