On 10/05, Oleg Nesterov wrote:
>
> On 10/05, Jan Kratochvil wrote:
> >
> > On Mon, 05 Oct 2009 04:51:32 +0200, Oleg Nesterov wrote:
>
> > > 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.

Just in case... If I change the test-case

        --- a/ptrace-tests/tests/attach-into-signal.c   2009-01-31 
13:11:40.000000000 -0800
        +++ b/ptrace-tests/tests/attach-into-signal.c   2009-09-20 
13:32:30.000000000 -0700
        @@ -225,9 +225,9 @@ static void reproduce (void)
               return;
             }
           assert (WIFSTOPPED (status));
        -  assert (WSTOPSIG (status) == SIGSTOP);
        +  assert (WSTOPSIG (status) == SIGPIPE);
           /* let tracee run. it must be killed very soon by SIGPIPE */
        -  ptrace (PTRACE_CONT, child, (void *) 1, (void *) 0);
        +  ptrace (PTRACE_CONT, child, (void *) 1, (void *) SIGPIPE);
           assert_perror (errno);
           pid = waitpid (child, &status, 0);
           assert (pid == child);

then it doesn't fail.

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

So... Jan, do you think this behaviour change can break gdb?

Oleg.

Reply via email to