On Thu, May 14, 2015 at 06:39:59PM +0200, Denys Vlasenko wrote: > On 05/14/2015 06:28 PM, Quentin Casasnovas wrote: > > Should we also add a little paragraph detailing that waitpid() would hang > > indefinitely if one thread terminates while the others are in ptrace-stop? > > It implies this by saying "but the subsequent WIFEXITED notification > will not be delivered until all other threads exit". > > If another thread is in ptrace-stop, it did not exit yet. Therefore, > WIFEXITED notification to the thread group leader will not be delivered. > Therefore, waitpid() on it would hang. > Right, I guess it just wasn't obvious to us (or just me) that the threads would not exit while in ptrace-stop. > > The only way for us to work-around this behaviour was to have > > PTRACE_O_TRACEEXIT and detach from the threads when we were notified of a > > thread termination, without PTRACE_O_TRACEEXIT I don't think one can be > > notified in way, leading to hangs almost certainly when tracing multiple > > threads and some are in ptrace-stop. > > Why do you do that waitpid on thread group leader? > > strace is the user of ptrace, and it has no problem with this behavior. > It simply waits for all tracees via waitpid(-1). Whichever sends the next > notification is processed. > That's because strace has all threads running; in our use-case, we attach to all threads of a group and restart a single thread to do some work. In this particular case, waitpid(-1, ...) does not help because to exit, the other threads need to be PTRACE_CONT'ed. Quentin -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
