Re: Race and segmentation fault in pthread_kill() vs thread teardown

Re: Race and segmentation fault in pthread_kill() vs thread teardown

[Mathieu Desnoyers]

----- Original Message -----
> From: "Andreas Schwab" <schwab@suse.de>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: "David Miller" <davem@davemloft.net>, libc-alpha@sourceware.org, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Sent: Wednesday, October 2, 2013 4:11:23 AM
> Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
> 
> The POSIX spec is pretty clear:
> 
>  If an application attempts to use a thread ID whose lifetime has ended,
>  the behavior is undefined.
> 
> I'd suggest to file a bug report with the Austin group wrt to the
> wording in pthread_kill.

CCing man pages maintainers,

Interestingly enough, the specification has been updated:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html

to remove the ESRCH return value in

Issue 7
  Austin Group Interpretation 1003.1-2001 #142 is applied, removing the [ESRCH] error condition.

It looks like a discrepancy between the spec and the man page that causes this confusion. We might want to update pthread_kill(3), keeping ESRCH documented, but clearly marked as deprecated, and clarify that calling pthread_kill() on a non-existing thread is undefined.

We should probably remove this part entirely:

"      but error checking is still per‐
       formed; this can be used to check for the existence of a thread ID."

Thoughts ?

Thanks,

Mathieu




> 
> Andreas.
> 
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: Race and segmentation fault in pthread_kill() vs thread teardown

[Roland McGrath]

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.

Re: Race and segmentation fault in pthread_kill() vs thread teardown

[Michael Kerrisk (man-pages)]

On 10/03/13 01:04, Mathieu Desnoyers wrote:
> ----- Original Message -----
>> From: "Andreas Schwab" <schwab@suse.de>
>> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> Cc: "David Miller" <davem@davemloft.net>, libc-alpha@sourceware.org, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> Sent: Wednesday, October 2, 2013 4:11:23 AM
>> Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
>>
>> The POSIX spec is pretty clear:
>>
>>  If an application attempts to use a thread ID whose lifetime has ended,
>>  the behavior is undefined.
>>
>> I'd suggest to file a bug report with the Austin group wrt to the
>> wording in pthread_kill.
> 
> CCing man pages maintainers,
> 
> Interestingly enough, the specification has been updated:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html
> 
> to remove the ESRCH return value in
> 
> Issue 7
>   Austin Group Interpretation 1003.1-2001 #142 is applied, removing the [ESRCH] error condition.
> 
> It looks like a discrepancy between the spec and the man page that causes this confusion. We might want to update pthread_kill(3), keeping ESRCH documented, but clearly marked as deprecated, and clarify that calling pthread_kill() on a non-existing thread is undefined.
> 
> We should probably remove this part entirely:
> 
> "      but error checking is still per‐
>        formed; this can be used to check for the existence of a thread ID."
> 
> Thoughts ?

Mathieu, et al.

I applied the patch below. Look okay to you?

Cheers,

Michael

diff --git a/man3/pthread_kill.3 b/man3/pthread_kill.3
index 674168f..bbf5573 100644
--- a/man3/pthread_kill.3
+++ b/man3/pthread_kill.3
@@ -47,8 +47,7 @@ The signal is asynchronously directed to
 
 If
 .I sig
-is 0, then no signal is sent, but error checking is still performed;
-this can be used to check for the existence of a thread ID.
+is 0, then no signal is sent, but error checking is still performed.
 .SH RETURN VALUE
 On success,
 .BR pthread_kill ()
@@ -58,13 +57,8 @@ on error, it returns an error number, and no signal is sent.
 .TP
 .B EINVAL
 An invalid signal was specified.
-.TP
-.B ESRCH
-No thread with the ID
-.I thread
-could be found.
 .SH CONFORMING TO
-POSIX.1-2001.
+POSIX.1-2008.
 .SH NOTES
 Signal dispositions are process-wide:
 if a signal handler is installed,
@@ -72,6 +66,19 @@ the handler will be invoked in the thread
 .IR thread ,
 but if the disposition of the signal is "stop", "continue", or "terminate",
 this action will affect the whole process.
+
+POSIX.1-2008 recommends that if an implementation detects the use
+of a thread ID after the end of its lifetime,
+.BR pthread_kill ()
+should return the error
+.BR ESRCH .
+The glibc implementation returns this error in the cases where
+an invalid thread ID can be detected.
+But note also that POSIX says that an attempt to use a thread ID whose
+lifetime has ended produces undefined behavior,
+and an attempt to use an invalid thread ID in a call to
+.BR pthread_kill ()
+can, for example, cause a segmentation fault.
 .SH SEE ALSO
 .BR kill (2),
 .BR sigaction (2),