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 32629 invoked from network); 22 Nov 2020 19:28:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Nov 2020 19:28:41 -0000 Received: (qmail 28220 invoked by uid 550); 22 Nov 2020 19:28:37 -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 28198 invoked from network); 22 Nov 2020 19:28:36 -0000 Date: Sun, 22 Nov 2020 14:28:25 -0500 From: Rich Felker To: Florian Weimer Cc: =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= , musl@lists.openwall.com, jwakely@redhat.com Message-ID: <20201122192824.GQ534@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> <20201122191106.GO534@brightrain.aerifal.cx> <87mtz99owk.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mtz99owk.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Mutexes are not unlocking On Sun, Nov 22, 2020 at 08:23:23PM +0100, Florian Weimer wrote: > * Rich Felker: > > > 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... > > 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: > > Uhg, that's a really nasty problem. Is __gthread_active_p() also inlined? Or can it be given a definition to mitigate the problem? Rich