From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30570 invoked from network); 22 Nov 2020 19:11:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Nov 2020 19:11:23 -0000 Received: (qmail 21805 invoked by uid 550); 22 Nov 2020 19:11:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21787 invoked from network); 22 Nov 2020 19:11:19 -0000 Date: Sun, 22 Nov 2020 14:11:07 -0500 From: Rich Felker To: =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= Cc: musl@lists.openwall.com Message-ID: <20201122191106.GO534@brightrain.aerifal.cx> References: <1605849917.737458858@f540.i.mail.ru> <1605941217.735966206@f110.i.mail.ru> <20201121155128.GN534@brightrain.aerifal.cx> <1606070615.957905591@f395.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1606070615.957905591@f395.i.mail.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Mutexes are not unlocking On Sun, Nov 22, 2020 at 09:43:35PM +0300, Арсений wrote: > > 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; > } Yes. This code is invalid (it misinterprets weak symbol information to draw incorrect conclusions about whether threads may be in use) and thus is disabled in builds of gcc/libstdc++ targeting musl-based systems. GCC and glibc-based distro folks mostly don't care because it only breaks static linking, but some of them actually hack gcc's libpthread.a into one giant .o file to work around the problem rather than fixing this in gcc... > 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: Yes. That's a standard requirement for building a musl-targeting gcc. >   > => 0x00007ffff7eb6dde <+0>: push %rdx > 0x00007ffff7eb6ddf <+1>: callq 0x7ffff7eaf550 > 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. Thanks for doing the root cause analysis here. It will be interesting (and probably infuriating) to the gcompat folks working on making glibc-linked binaries work on musl, but maybe they already have a workaround for this. Anyway the answer to your original question is probably just "don't do that" unless you want to get into fixing GCC... Rich