|
Message-ID: <20201122192824.GQ534@brightrain.aerifal.cx> Date: Sun, 22 Nov 2020 14:28:25 -0500 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fw@...eb.enyo.de> Cc: Арсений <a@...r0n.science>, musl@...ts.openwall.com, jwakely@...hat.com Subject: Re: Mutexes are not unlocking On Sun, Nov 22, 2020 at 08:23:23PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Sun, Nov 22, 2020 at 09:43:35PM +0300, Арсений wrote: > >> > >> Hello, > >> The problem is that mutex is not got unlocked after the first unlock(). > >> > >> libstdc++ uses a wrapper for pthread called gthreads. This wrapper > >> checks for the state of the mutex system. For > >> example, pthread_mutex_unlock() is called in a following way: > >> > >> static inline int > >> __gthread_mutex_unlock (__gthread_mutex_t *__mutex) > >> { > >> if (__gthread_active_p ()) > >> return __gthrw_(pthread_mutex_unlock) (__mutex); > >> else > >> return 0; > >> } > > > > Yes. This code is invalid (it misinterprets weak symbol information to > > draw incorrect conclusions about whether threads may be in use) and > > thus is disabled in builds of gcc/libstdc++ targeting musl-based > > systems. GCC and glibc-based distro folks mostly don't care because > > it only breaks static linking, but some of them actually hack gcc's > > libpthread.a into one giant .o file to work around the problem rather > > than fixing this in gcc... > > GCC 11 has a fix (if used along with glibc 2.32), but I wonder if it's > going to run into a similar issue because inlined code from older GCC > versions uses a diverging version of the check. > > Jonathan, more context is here: > > <https://www.openwall.com/lists/musl/2020/11/22/1> Uhg, that's a really nasty problem. Is __gthread_active_p() also inlined? Or can it be given a definition to mitigate the problem? Rich
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.