utrace-ptrace && detach with signal semantics

[Oleg Nesterov]

On 10/05, Jan Kratochvil wrote:
>
> 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.

They should not, this is just wrong.

And I think the proposed change doesn't change the behaviour
in this sense.

> > 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.

This test-case also does:

	/* detach with SIGPIPE/attach. This should kill tracee */
	ptrace (PTRACE_DETACH, child, (void *) 1, (void *) SIGPIPE);

	ptrace (PTRACE_ATTACH, child, (void *) 0, (void *) 0);

	waitpid (child, &status, 0);
	assert (WIFSIGNALED (status) && WTERMSIG (status) == SIGPIPE);

It fails if the second PTRACE_ATTACH sees SIGPIPE. This is what
I can't understand.

> > 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

Hmm. Could you please explain what "testcase looping" above mean?


Perhaps we don't understand each other...

OK. Currently, ptrace(DETACH, SIGXXX) means:

	- untrace

	- the tracee will get this SIGXXX and handle this signal

	- BUT! if the new tracer attaches right now, before the
	  tracee handles the signal, this signal will not be
	  reported to the new tracer.

With the current utrace-ptrace implementation: if the second
attach happens before the tracee dequeues SIGXXX, this signal
will be reported to the new tracer too.

Oleg.