Oleg Nesterov <[email protected]> writes: > On 12/17, Eric W. Biederman wrote: >> >> Oleg Nesterov <[email protected]> writes: >> >> > Suppose we have 2 threads, the group-leader L and a sub-theread T, >> > both parked in ptrace_stop(). Debugger tries to resume both threads >> > and does >> > >> > ptrace(PTRACE_CONT, T); >> > ptrace(PTRACE_CONT, L); >> > >> > If the sub-thread T execs in between, the 2nd PTRACE_CONT doesn not >> > resume the old leader L, it resumes the post-exec thread T which was >> > actually now stopped in PTHREAD_EVENT_EXEC. In this case the >> > PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the >> > tracee changed its pid. >> >> The change seems sensible. I don't expect this is common but it looks >> painful to deal with if it happens. > > Yes, this is not a bug, but gdb can't handle this case without some help > from the kernel.
>> I admit this a threaded PTRACE_EVENT_EXEC is the only event we are >> likely to miss but still. > > Yes, this is the only event debugger can miss even if it uses wait() > correctly. I think that is my confusion with the patch. The uniqueness of this case is not described well. Eric
