[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 26 Feb 2017 12:48:07 +0300
From: Леонид Юрьев <leo@...iev.ru>
To: musl@...ts.openwall.com
Subject: ldso pthread finalization
Hi,
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
__nptl_deallocate_tsd().
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().
== https://sourceware.org/bugzilla/show_bug.cgi?id=21031
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 lib.so.
== https://sourceware.org/bugzilla/show_bug.cgi?id=21032
Regards,
Leonid.
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.
