Re: [musl] Mutexes are not unlocking

[Rich Felker <dalias@libc.org>]

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