Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mtz99owk.fsf@mid.deneb.enyo.de>
Date: Sun, 22 Nov 2020 20:23:23 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: Арсений <a@...r0n.science>,
  musl@...ts.openwall.com, jwakely@...hat.com
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:

  <https://www.openwall.com/lists/musl/2020/11/22/1>

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.