On 12/17/20 11:39 PM, Eric W. Biederman wrote: >> 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.
Yeah, the debug session becomes completely messed up, as the ptracer has no idea the process is running a new image, breakpoints were wiped out, and the post-exec process is resumed without the ptracer having had a chance to install new breakpoints. I don't see any way to deal with it without kernel help. > > Acked-by: "Eric W. Biederman" <ebied...@xmission.com> > > I am wondering if this should be expanded to all ptrace types for > consistency. Or maybe we should set a flag to make this happen for > all ptrace events. > > It just seems really odd to only worry about missing this event. > I admit this a threaded PTRACE_EVENT_EXEC is the only event we are > likely to miss but still. It's more about the tid stealing than the event itself. I mean, we lose the event because the tid changes magically without warning. An exec is the only scenario where this happens. > > Do you by any chance have any debugger/strace test cases? > > I would think that would be the way to test to see if this breaks > anything. I think I remember strace having a good test suite. I ran the GDB testsuite against this, no regressions showed up. BTW, the problem was discovered by Simon Marchi when he tried to write a GDB testcase for a multi-threaded exec scenario: https://sourceware.org/bugzilla/show_bug.cgi?id=26754 I've went through GDB's code looking for potential issues with the change and whether it would affect GDBs already in the wild. Tricky corner cases abound, but I think we're good. Feel free to add my ack: Acked-by: Pedro Alves <pal...@redhat.com> Thanks, Pedro Alves
