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 32036 invoked from network); 22 Nov 2020 19:23:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Nov 2020 19:23:41 -0000 Received: (qmail 26043 invoked by uid 550); 22 Nov 2020 19:23:40 -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 26022 invoked from network); 22 Nov 2020 19:23:39 -0000 From: Florian Weimer To: Rich Felker Cc: =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= , musl@lists.openwall.com, jwakely@redhat.com References: <1605849917.737458858@f540.i.mail.ru> <1605941217.735966206@f110.i.mail.ru> <20201121155128.GN534@brightrain.aerifal.cx> <1606070615.957905591@f395.i.mail.ru> <20201122191106.GO534@brightrain.aerifal.cx> Date: Sun, 22 Nov 2020 20:23:23 +0100 In-Reply-To: <20201122191106.GO534@brightrain.aerifal.cx> (Rich Felker's message of "Sun, 22 Nov 2020 14:11:07 -0500") Message-ID: <87mtz99owk.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Mutexes are not unlocking * Rich Felker: > On Sun, Nov 22, 2020 at 09:43:35PM +0300, =D0=90=D1=80=D1=81=D0=B5=D0=BD= =D0=B8=D0=B9 wrote: >>=20 >> Hello, >> The problem is that mutex is not got unlocked after the first unlock(). >> =C2=A0 >> libstdc++ uses a wrapper for pthread called gthreads. This wrapper >> checks for the state of the mutex system. For >> example,=C2=A0pthread_mutex_unlock() is called in a following way: >> =C2=A0 >> 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... GCC 11 has a fix (if used along with glibc 2.32), but I wonder if it's going to run into a similar issue because inlined code from older GCC versions uses a diverging version of the check. Jonathan, more context is here: