From: Арсений <a@saur0n.science>
To: "Rich Felker" <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re[2]: [musl] Mutexes are not unlocking
Date: Sun, 22 Nov 2020 21:43:35 +0300 [thread overview]
Message-ID: <1606070615.957905591@f395.i.mail.ru> (raw)
In-Reply-To: <20201121155128.GN534@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 4092 bytes --]
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;
}
The function __gthread_active_p() is an inline function which returns non-nullptr value is pthreads is available.
It seems that std::mutex::lock() in libstdc++ from Alpine Linux repos does not use ghtreads:
=> 0x00007ffff7eb6dde <+0>: push %rdx
0x00007ffff7eb6ddf <+1>: callq 0x7ffff7eaf550 <pthread_mutex_lock@plt>
0x00007ffff7eb6de4 <+6>: test %eax,%eax
0x00007ffff7eb6de6 <+8>: je 0x7ffff7eb6def <_ZNSt5mutex4lockEv+17>
0x00007ffff7eb6de8 <+10>: mov %eax,%edi
0x00007ffff7eb6dea <+12>: callq 0x7ffff7eb3f50 <_ZSt20__throw_system_errori@plt>
0x00007ffff7eb6def <+17>: pop %rax
0x00007ffff7eb6df0 <+18>: retq
std::mutex::lock() from glibc-compatible libstdc++ is not inlined by compiler during build, because it contains check for errors:
void
lock()
{
int __e = __gthread_mutex_lock(&_M_mutex);
// EINVAL, EAGAIN, EBUSY, EINVAL, EDEADLK(may)
if (__e)
__throw_system_error(__e);
}
std::mutex::unlock() from glibc-compatible libstdc++ is inlined, because it does not contain anything but call to __gthread_mutex_lock():
void
unlock()
{
// XXX EINVAL, EAGAIN, EPERM
__gthread_mutex_unlock(&_M_mutex);
}
This is why pthread_mutex_lock() from musl is called, but pthread_mutex_unlock() is not.
>Суббота, 21 ноября 2020, 18:51 +03:00 от Rich Felker <dalias@libc.org>:
>
>On Sat, Nov 21, 2020 at 09:46:57AM +0300, a@saur0n.science wrote:
>> Hello,
>> Thanks for the fast response.
>>
>> I compiled binary under OpenSUSE towards glibc and started on Alpine
>> Linux.
>
>I think you mean just compiled normally on OpenSUSE without doing
>anything related to musl at this point, but could you please conform
>that that's the case?
>
>Also, did you link libstdc++ statically or dynamically? Are you moving
>any additional shared libraries over from the glibc system, or just
>the application binary? Does it have any other libraries static linked
>into it?
>
>This is why I asked for full information on how you built it. The
>answers to these questions determine what direction you should look
>in.
>
>musl provides some minimal level of glibc-ABI-compat for attempting to
>get binaryware that you can't rebuild against musl to work. This
>doesn't mean building binaries for glibc and attempting to use them
>with musl is necessarily supported usage. It's possible that you're
>doing something that just can't work, but it's also possible that
>there are simple mistakes you could correct and get this working.
>
>> I think it is not a problem because mutex is aggregated by a
>> pointer.
>
>I'm also not clear exactly what you mean by that.
>
>> 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 means the problem is in something you haven't shown or described.
>
>> 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>}
>
>This is printing out a glibc data structure, which isn't going to be
>meaningful.
>
>Rich
——
Арсений
[-- Attachment #2: Type: text/html, Size: 6595 bytes --]
next prev parent reply other threads:[~2020-11-22 18:46 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 ` Re[2]: " a
2020-11-21 15:51 ` Rich Felker
2020-11-22 18:43 ` Арсений [this message]
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=1606070615.957905591@f395.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).