Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Feb 2017 12:48:07 +0300
From: Леонид Юрьев <>
Subject: ldso pthread finalization


In glibc there are a couple of problems. I do not know whether they
are relevant for Musl. However, I think should pay attention.

So, please take in accound two glibc bugs:

1) pthread_key_delete() race with thread finalization.

A race condition could occur between the pthread_key_delete() and the

For instance, __nptl_deallocate_tsd() could call a destructor for the
key, immediately before the pthread_key_delete() invalidates it (from
an another thread), and will continue destructor execution after the
completion of pthread_key_delete().

>From a user code this looks as if the corresponding destructor
executes after the key has been removed by pthread_key_delete(), and
there is no way to know whether was destructor called/executed or not.

Suggest add pthread_rwlock_rdlock() for __nptl_deallocate_tsd() and
pthread_rwlock_wrlock() for pthread_key_delete().

2) pthread_key_create() destructors and segfault after a DSO unloading.

The pthread_key_create() and __nptl_deallocate_tsd() do not track the
references to destructor's DSO like the __cxa_thread_atexit_impl().

Therefore the DSO, which holds a destructor's code, could be unloaded
before destructor execution or before deleting a corresponding key.

So in a complex environment there is no way to know whether it is safe
to unload a particular DSO or some tls-destructors are still left.

Suggest this should be fixed or documented, e.g. that the
pthread_create_key() with a destructor should not be used from


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.