[<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.
