On Mon, 2 Feb 2004, Andries Brouwer wrote: > > So, I think what happens is that PTRACE_KILL immediately after the PTRACE_CONT > works because there is no schedule in between, so the effect of PTRACE_KILL > is still seen by the (grand)child. Well, Duh! You'r eobviously right. PTRACE_KILL is a special case, since it's supposed to work _regardless_ of whether the process being traced is actually stopped for tracing or not. And Roland is correct that PTRACE_KILL works fine _if_ it is stopped. But for the case where it isn't (and Daniel's program isn't, since it did the PTRACE_CONT), PTRACE_KILL does nothing. > Maybe there is no bug. No, I do believe that PTRACE_KILL is supposed to kill the child even if it wasn't synchronized. See the special case for "ptrace_check_attach()", which allows a PTRACE_KILL to happen even for a nonsynchronized target. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo _at_ vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
References:
- Re: More waitpid issues with CLONE_DETACHED/CLONE_THREADRoland McGrath
- Re: More waitpid issues with CLONE_DETACHED/CLONE_THREADLinus Torvalds
- Re: More waitpid issues with CLONE_DETACHED/CLONE_THREADAndries Brouwer
- Prev by Date: Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD
- Next by Date: Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD
- Previous by thread: Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD
- Next by thread: Re: More waitpid issues with CLONE_DETACHED/CLONE_THREAD
- Indexes:[Main][Thread]