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? This behaviour was quite puzzling as during our experiments, waitpid(<thread_pid>, ...) was hanging on a zombie thread, and even using waitpid(-1, ...) wasn't helping. 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. 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." I know we didn't realize the other threads would not exit (because they were in ptrace-stop), blocking the delivery. 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
