On 05/14/2015 06:39 PM, Denys Vlasenko wrote:
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.
While I agree that the information in the current man page is strictly
speaking sufficient, I personally still think it would be an improvement
to mention it explicitly (i.e. my proposed change #2 in the original
e-mail). Just because I think it's a sort of non-obvious pitfall; out of
hand, you don't expect a call to waitpid() on a process that has exited
to hang. That's just my opinion, though.
Vegard
--
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
