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 --]
next prev parent 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).