Hello,
Thanks for the fast response.

I compiled binary under OpenSUSE towards glibc and started on Alpine Linux. I think it is not a problem because mutex is aggregated by a pointer.

I am using gcc 10.2.1 20201028 [revision a78cd759754c92cecbf235ac9b447dcdff6c6e2f] installed from OpenSUSE reporitories.

Unfortunately, I cannot post a "minimal working example", because the bug does not reproduce on a small programs.

This is the internal state of the mutex which caused problems at the moment of second lock operation:
(gdb) print gsMutex 
$1 = {<std::__mutex_base> = {_M_mutex = {__data = {__lock = 0, __count = 2147483664, __owner = 1, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { 
         __prev =  0x0 , __next =  0x0 }}, __size = "\000\000\000\000\020\000\000\200\001", '\000' <repeats 30 times>, __align = -9223371968135299072}}, <No data fields>}

Backtrace:
#0   __syscall_cp_c ( nr =<optimized out>,  u =140737352115364,  v =128,  w =-2147483632,  x =0,  y =0,  z =0) at  ./arch/x86_64/syscall_arch.h :61 
#1   0x00007ffff7fbcacf in  __timedwait_cp ( addr=addr@entry =0x7ffff7e124a4 <gsMutex+4>,  val=val@entry =-2147483632,  clk=clk@entry =0,  at=at@entry =0x0,  
    priv =<optimized out>,  priv@entry =128) at  src/thread/__timedwait.c :31 
#2   0x00007ffff7fbcb69 in  __timedwait ( addr=addr@entry =0x7ffff7e124a4 <gsMutex+4>,  val =-2147483632,  clk=clk@entry =0,  at=at@entry =0x0,  priv=priv@entry =128) 
   at  src/thread/__timedwait.c :48 
#3   0x00007ffff7fbeb4b in  __pthread_mutex_timedlock ( m =0x7ffff7e124a0 <gsMutex>,  at =0x0) at  src/thread/pthread_mutex_timedlock.c :67 
#4   0x00007ffff7eb6de4 in  std::mutex::lock() () from /usr/lib/libstdc++.so.6 
#5   0x00007ffff7e0e363 in  testMutex ( mtx =...,  name=name@entry =0x7ffff7e0f1fa "gsMutex") at  Session.cpp :27
(

>Пятница, 20 ноября 2020, 8:58 +03:00 от Rich Felker <dalias@libc.org>:
>
>On Fri, Nov 20, 2020 at 08:25:17AM +0300,  a@saur0n.science wrote:
>> Hello, all,
>> I am experiencing a problem with mutexes in musl-libc. The mutex is
>> not unlocked after calling unlock(), this causes getting stuck on
>> attempt to lock it next time. Example code (C++):
>> 
>> void testMutex(std::mutex &mtx, const char * name) {
>> fprintf(stderr, "-- testing %s --\n", name);
>> fprintf(stderr, "lock\n");
>> mtx.lock();
>> fprintf(stderr, "unlock\n");
>> mtx.unlock();
>> fprintf(stderr, "lock2\n");
>> mtx.lock();
>> fprintf(stderr, "unlock2\n");
>> mtx.unlock();
>> fprintf(stderr, "done\n");
>> }
>> The problem can be reproduced only on musl-libc, the same binary
>> works well on the system with glibc.
>The same binary? Do you mean you have a glibc-built binary you're
>trying to use with musl? Or did you mean to say the same source
>program?
>
>> The problem does not reproduce each time, its reproducibility
>> depends on the phase of moon.
>> The problem can be reproduced more often it the code calling mutex
>> functions is located in the shared library.
>> 
>> Strace (when the problem is reproduced):
>> [pid   709] writev(2, [{iov_base="-- testing gsMutex --\n", iov_len=22}, {iov_base=NULL, iov_len=0}], 2-- testing gsMutex -- 
>> ) = 22 
>> [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="lock\n", iov_len=5}], 2lock 
>> ) = 5 
>> [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock\n", iov_len=7}], 2unlock 
>> ) = 7 
>> [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="lock2\n", iov_len=6}], 2lock2 
>> ) = 6 
>> [pid   709] futex(0x7f3a9733e4a4, FUTEX_WAIT_PRIVATE, 2147483664, NULL
>> 
>> Strace (when the problem is not reproduced):
>> writev(2, [{iov_base="-- testing hhMutex --\n", iov_len=22}, {iov_base=NULL, iov_len=0}], 2-- testing hhMutex -- 
>> ) = 22 
>> writev(2, [{iov_base="", iov_len=0}, {iov_base="lock\n", iov_len=5}], 2lock 
>> ) = 5 
>> writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock\n", iov_len=7}], 2unlock 
>> ) = 7 
>> writev(2, [{iov_base="", iov_len=0}, {iov_base="lock2\n", iov_len=6}], 2lock2 
>> ) = 6 
>> writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock2\n", iov_len=8}], 2unlock2 
>> ) = 8 
>> writev(2, [{iov_base="", iov_len=0}, {iov_base="done\n", iov_len=5}], 2done 
>> ) = 5
>> 
>> Thanks in advance for solving the problem.
>
>Can you post the full test case and information on how you built it,
>including what compiler you're using (whether it's from a distro, or
>one you built yourself, or what)?
>
>Rich


—— 
Арсений
minimal   working   example