Date: Sun, 26 Feb 2017 12:41:07 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: ???????????? ?????????? <leo@...iev.ru> Cc: musl@...ts.openwall.com Subject: Re: ldso pthread finalization * ???????????? ?????????? <leo@...iev.ru> [2017-02-26 12:48:07 +0300]: > 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 > i dont think the standard requires that dtors must finish running when pthread_key_delete returns: a long running dtor could hold up pthread_key_delete indefinitely. if there were a lock, like you suggest, then the dtor could deadlock when it synchronizes with other threads doing a pthread_key_delete. the standard is not very clear, so it is better to treat it unspecified if dtors must finish or not. > > 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 > the standard even gives this as an example why there is pthread_key_delete: it's the user's responsibility to delete keys registered by the dso before dso unload. http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_key_delete.html one could argue that in c++ unloading a dso with tls dtors is undefined so you should not rely on that working either. (dso tracking logic requires special abi which a platform may or may not have in place, the standard does not say anything about this. in particular the hack that is used to track the dsos of atexit handlers is non-conforming so at least dlclose+atexit cannot work the way you expect on a conforming system.) in any case, musl is not affected because its dlclose is a nop.
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.