Sources Bugzilla – Bug 4509
pthread_kill() Segmentation Fault when TID is invalid
Last modified: 2010-12-21 13:26:22 UTC
pthread_kill should return ERROR ESRCH instead of crashes when receive a invalid
TID on parameter pthread_t thread.
This occurs on OpenSuse 10.2, with NPTL and don't occurs in Conectiva 9.
The example below never reach to the print function, it crashes on pthread_kill.
= The pthread_kill() function shall fail if:
= ESRCH No thread could be found corresponding to that specified by the
= given thread ID.
int main (int argc, char* const argv )
int iRet = 0;
iRet = pthread_kill (123, 0);
printf("iRet = %d\n", iRet);
Linux 184.108.40.206-34-default i686 athlon i386 GNU/Linux
The thread library has no obligation to catch invalid thread IDs. It cannot.
Your code is wrong.
What is the porpose of the error code ESRCH if the thread library has no
obligation to catch invalid thread ID ??
How can i verify if a thread is dead or alive ?
(In reply to comment #2)
> The thread library has no obligation to catch invalid thread IDs. It cannot.
> Your code is wrong.
What is the purpose of the error code ESRCH if the thread library has no
obligation to catch invalid thread ID ??
How can i verify if a thread is dead or alive if when i send a signal to ask, my
application is going down. Is it difficult to implement an error message of an
invalid id ?
Let say POSIX do not say anything about it, but we could not allow a
Segmentation Fault ERROR. Don't you think ?
Dear Mr Ulrich, as the "The Open Group Technical Standard - Base Specifications,
Issue 6 - System Interfaces" document stands, which includes IEEE Std
1003.1-2001, IEEE Std 1003.1-2001/Cor 1-2002 and IEEE Std 1003.1-2001/Cor 2-2004
specifications, and which specify how threads are implemented following POSIX
patterns and for which you can verify by yourself, the implementation of the
pthread_kill() system call (page 1132) stands that the pthread_kill *shall*
return ESRCH err in case "no thread could be found corresponding to that
specified by the given thread ID". So we can conclude that pthread_kill()
implementation is _not_ following the POSIX specifications. I still remember
that there is another bug (#60) that had already signaled that kind of problem.
In case of the pthread_cancel system call (page 1078) there is the same
situation, the specification says that it shall return the indicative error, ESRCH.
Stop reopening the bug. I understand the specification very well, I help
writing it. It is not my problem that your application is broken and that you
don't understand the specification.
Ulrich, please tell me, why in the specification says that pthread_kill "*shall*
return error, and list ESRCH as a possible error ? What it means for you ? Is it
possible other interpretation ?
I ask you just to look at the specification in the pthread_kill section and
think about it, ok ?
Read the Austin Group communications. I'm not paid to do your work for you.
Dear Mr. Ulrich, as we can see at various mailing lists and also lots of tickets
about the behaviour of the pthread_kill() and your unpolite answers about the
theme, I am going to ask the same way you treat people when they ask about this
Stop saying the others's code is wrong. Your pthread_kill() implementation is
not in accordance with POSIX at all. As a C coder, I'm completely astounted how
a unpolite person like you cannot apply a patch already proposed in order to be
compliant with POSIX. If "must return ESRCH" is not compliant with POSIX in case
of an invalid TID, so point us out where a hell this document is. No one can
find that document!! Nor at the Opengroup nor at Austin Group!! Only you guy
keep saying the code is wrong!! Show us the right code or point us to the
document saying you are right!
Take a look at:
and all the documents about pthread_kill(). If you are right and you are the guy
who made the specification, so show us the "correct" specification. All the
specifications I could buy and look at the Internet show us you are completely
wrong!! Shame on you.
Please check http://udrepper.livejournal.com/tag/programming+posix
(For reference, the blog post is: http://udrepper.livejournal.com/16844.html)