On 05/14/2015 06:28 PM, Quentin Casasnovas wrote: > On Thu, May 14, 2015 at 03:52:36PM +0200, Denys Vlasenko wrote: >> On 05/14/2015 03:44 PM, Michael Kerrisk (man-pages) wrote: >>> Hi Denys, >>> >>> Do you have any thoughts on the below? >> >> Yes, the poster is right: this part needs fixing, the behavior is >> the same on any kind of process termination. >> >> >>> On 05/12/2015 04:31 PM, Vegard Nossum wrote: >>>> We hit another edge case in the ptrace() interface and after several >>>> hours of chasing it down, we found that it was already described in the >>>> "BUGS" section: >>>> >>>> "If a thread group leader is traced and exits by calling _exit(2), a >> >> I think a possible fix is just to replace "exits by calling _exit(2)" part >> of the above text with "terminates". >> > > 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. > 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. > Or maybe that's obvious from the following sentence: > > "If a thread group leader is traced and exits by calling _exit(2), a > PTRACE_EVENT_EXIT stop will happen for it (if requested), but the > subsequent WIFEXITED notification will not be delivered until all other > threads exit." Exactly. -- 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
