Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Feb 2020 21:23:20 +0100
From: Markus Wichmann <>
Subject: Re: No such process return value in pthread_getcpuclockid

On Mon, Feb 10, 2020 at 10:57:22PM +0300, Alexander Scherbatiy wrote:
> I can create a thread, join to it and use the thread id in
> pthread_getcpuclockid function after that.

Nope, that's a use after free. Joining a thread has the effect of
invalidating all outstanding pthread_ts for the joined thread.

> The Linux Programmer's Manual has the following errors section: "ESRCH  No
> thread with the ID thread could be found."

And POSIX says "No errors are defined." I'm guessing POSIX wins.
Use-after-free in this case would be dangerous even if it did not crash.
See, once a thread is joined, the pthread_t is invalidated, but it may
be reused. Another thread may immediately create another thread that
coincidentally allocates the pthread_t in exactly the same place as the
old pthread_t was. Not as coincidental as one might think if both
threads have the same stack and guard size.

Once that has happened, pthread_getcpuclockid (or any other pthread_*
function) will access a different thread than you intended. It is a
logic error to do what you want to do, and crashing is one of the best
things that can happen to you if you try. The other possibility is a
really subtle bug that only occurs sometimes. Happy debugging!

> Does pthread_getcpuclockid function from musl follows the similar errors
> handling approach?

Musl's pthread_getcpuclockid() cannot fail at this time. It can only
succeed or crash.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.