On 10/06, Jan Kratochvil wrote: > > On Mon, 05 Oct 2009 21:00:37 +0200, Oleg Nesterov wrote: > > 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. > > That may be a right point but such programs are in use out there. Sure if it > would be a real difficulty one can keep it as-is as GDB-7.0 soon to be > released has it already fixed, strace works with it. Still ltrace crashes the > inferior in such case.
Confused. Do you mean we should fix the kernel to match this expectation? This was never true. PTRACE_ATTACH sends SIGSTOP to the tracee, but this SIGSTOP is not magical, there is no any guarantee it will be dequeued before other pending signals. You attached the test-case which sends SIGALRM to itself in a loop. If the tracer attaches to this program, it is very possible that SIGALRM will be reported, not SIGSTOP. But! this has nothing to do with the question I asked ;) see below. > > And I think the proposed change doesn't change the behaviour > > in this sense. > > We started to discuss two different changes: We started to discuss 3 different things, not 2. Please see below, my question was quite different. > my asked for one: ptrace(DETACH, SIGSTOP) should leave the tracee stopped. Yes, > a new one: First signal after PTRACE_ATTACH should be SIGSTOP. This was never true, afaics. Of course, if nobody sends other signals to the tracee then SIGSTOP will be the first signal, but only because there are no other signals which could be dequeued/reported. > > > > 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. > > attach-info-signal from the ptrace-testsuite does not FAIL for me. Which > kernel version does it FAIL on for you? It fails on ptrace-over-utrace. And I can't understand why this behaviour is important. I hope it is not. Once again. Suppose that the tracer does ptrace(PTRACE_DETACH, SIGXXX). Currently, if the next thacer attaches right after this detach it has no way to intercept SIGXXX, it will be never reported via ptrace_signal(). Is this really important? Do you know any application which can be broken if we change this behaviour? With the current utrace-ptrace implementation SIGXXX can be reported to the new tracer. OK, this relates to "the first signal should be SIGSTOP" but this is wrong anyway, and the case above is very unlikely. Oleg.
