Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Nov 2020 20:23:23 +0100
From: Florian Weimer <>
To: Rich Felker <>
Cc: Арсений <>,,
Subject: Re: Mutexes are not unlocking

* 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:


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.