[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
