This is the mail archive of the
mailing list for the glibc project.
Re: Race and segmentation fault in pthread_kill() vs thread teardown
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, Michael Kerrisk <mtk dot manpages at gmail dot com>, David Miller <davem at davemloft dot net>, libc-alpha at sourceware dot org, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, linux-man at vger dot kernel dot org
- Date: Wed, 2 Oct 2013 11:05:13 -0700 (PDT)
- Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
- Authentication-results: sourceware.org; auth=none
- References: <305581948 dot 26980 dot 1380684877897 dot JavaMail dot zimbra at efficios dot com> <675415986 dot 27031 dot 1380686764309 dot JavaMail dot zimbra at efficios dot com> <mvm8uyc2itw dot fsf at hawking dot suse dot de> <1497173819 dot 27140 dot 1380715480773 dot JavaMail dot zimbra at efficios dot com>
Yes, the man page is wrong. It was an error in the earlier version of the
spec that it indicated it's ever possible to do any operation with a
pthread_t that is not known to be an unjoined or live (if detached) thread.
It's never been possible to use a possibly-stale pthread_t for anything in
NPTL. There is no way to interrogate the system for whether a pthread_t
value is valid--just like a pointer (which, in fact pthread_t is in our
implementation), either it's valid or using it is undefined behavior.