Re: [musl] Mutexes are not unlocking

[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