mailing list of musl libc
 help / color / mirror / code / Atom feed
From: a@saur0n.science
To: "Rich Felker" <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re[2]: [musl] Mutexes are not unlocking
Date: Sat, 21 Nov 2020 09:46:57 +0300	[thread overview]
Message-ID: <1605941217.735966206@f110.i.mail.ru> (raw)
In-Reply-To: <20201120055828.GL534@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 4523 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 18572 bytes --]

  reply	other threads:[~2020-11-21 13:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20  5:25 a
2020-11-20  5:58 ` Rich Felker
2020-11-21  6:46   ` a [this message]
2020-11-21 15:51     ` Rich Felker
2020-11-22 18:43       ` Re[2]: " Арсений
2020-11-22 19:11         ` Rich Felker
2020-11-22 19:23           ` Florian Weimer
2020-11-22 19:28             ` Rich Felker
2020-11-22 19:45               ` Re[2]: " Арсений
2020-11-22 20:05               ` Арсений
2020-11-23 12:24                 ` Jonathan Wakely
2020-11-23 14:56                   ` Rich Felker
2020-11-23 16:58                     ` Jonathan Wakely
2020-11-23 11:41               ` Jonathan Wakely
2020-11-23 14:53                 ` Rich Felker
2020-11-23 16:19                   ` Jonathan Wakely
2020-11-23 16:51                     ` Rich Felker
2020-11-23 17:10                       ` Jonathan Wakely
2020-11-23 17:18                         ` Florian Weimer
2020-11-23 16:59                     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1605941217.735966206@f110.i.mail.ru \
    --to=a@saur0n.science \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).