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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 22363 invoked from network); 23 Nov 2020 17:00:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Nov 2020 17:00:17 -0000 Received: (qmail 26361 invoked by uid 550); 23 Nov 2020 17:00:15 -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 24113 invoked from network); 23 Nov 2020 16:58:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606150719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+FQGJCmbPtGH/JvJSqcP/3JEHh1G3Z44CaNMVmLtNTE=; b=i1koo/RU8VNRJJKIXUsJ/wNcqTR8DmFJniLgTSwTk13bcOaQWf4la0q2+x8FA+vZ2RG+S/ yWzZlJynvXcVDxBNTUMgNs9CmAh6juo+NF70W3gnMbw/EKe65hoAniL9/fdDS6DTpVQLaV Lq1SdtX5xBWgdNvZ9HNTsYD9DqaL0es= X-MC-Unique: U_cxLZZLN-WBq5l3p8t8bQ-1 Date: Mon, 23 Nov 2020 16:58:33 +0000 From: Jonathan Wakely To: Rich Felker Cc: =?utf-8?B?0JDRgNGB0LXQvdC40Lk=?= , musl@lists.openwall.com, Florian Weimer Message-ID: <20201123165833.GU1312820@redhat.com> References: <1605849917.737458858@f540.i.mail.ru> <87mtz99owk.fsf@mid.deneb.enyo.de> <20201122192824.GQ534@brightrain.aerifal.cx> <1606075554.931961164@f189.i.mail.ru> <20201123122428.GQ1312820@redhat.com> <20201123145628.GV534@brightrain.aerifal.cx> MIME-Version: 1.0 In-Reply-To: <20201123145628.GV534@brightrain.aerifal.cx> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jwakely@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: Re: [musl] Mutexes are not unlocking On 23/11/20 09:56 -0500, Rich Felker wrote: >On Mon, Nov 23, 2020 at 12:24:28PM +0000, Jonathan Wakely wrote: >> On 22/11/20 23:05 +0300, Арсений wrote: >> > >> >Hello, >> >  >> >I fixed the problem by making a workaround. Specifying -D_GLIBCXX_GTHREAD_USE_WEAK=0 forces libstdc++ headers do not use weak symbols. Mutexes are correctly locked and unlocked now. >> >> That might "work" but is unsupported, because that macro is for >> libstdc++'s internal use, not for users to define/undefine. >> >> But then libstdc++ doesn't support being compiled/linked against a >> glibc libstdc++ and then running against musl at runtime (I didn't >> even know that was an option until today) so one more unsupported >> thing probably won't hurt :-) >> >> Maybe we should just bless the use of that macro as supported, which >> would solve https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 > >As you noted in comment 2, that won't fix the uses internal to >libstdc++.{so,a}, only the inlined ones. I think this could give the >wrong behavior in the opposite direction -- calling unlock without >lock, thereby causing an error (for error-checking mutexes) or trap >(if UB catching traps are in place for other types). I've just had a quick look, and (for linux targets) the only case I found where there's a lock outside the library (in user code) and a corresponding unlock inside the library, or vice versa, is in std::notify_all_at_thread_exit. (I only looked very quickly, so there might be other cases I missed). It does look like it would be possible for user code to lock the mutex (via a direct all to the non-weak pthread_mutex_lock) and then call std::notify_all_at_thread_exit() which unlock the mutex, which would test __gthread_active_p, which would incorrectly think the program is single-threaded, and not call pthread_mutex_unlock. So recommending -D_GLIBCXX_GTHREAD_USE_WEAK=0 is a bad idea. We would need a better way for users to override the checks.