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 718 invoked from network); 20 Nov 2020 05:58:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Nov 2020 05:58:49 -0000 Received: (qmail 22527 invoked by uid 550); 20 Nov 2020 05:58:46 -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 22509 invoked from network); 20 Nov 2020 05:58:46 -0000 Date: Fri, 20 Nov 2020 00:58:34 -0500 From: Rich Felker To: a@saur0n.science Cc: musl@lists.openwall.com Message-ID: <20201120055828.GL534@brightrain.aerifal.cx> References: <1605849917.737458858@f540.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1605849917.737458858@f540.i.mail.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Mutexes are not unlocking On Fri, Nov 20, 2020 at 08:25:17AM +0300, a@saur0n.science wrote: > Hello, all, > I am experiencing a problem with mutexes in musl-libc. The mutex is > not unlocked after calling unlock(), this causes getting stuck on > attempt to lock it next time. Example code (C++): > > void testMutex(std::mutex &mtx, const char * name) { > fprintf(stderr, "-- testing %s --\n", name); > fprintf(stderr, "lock\n"); > mtx.lock(); > fprintf(stderr, "unlock\n"); > mtx.unlock(); > fprintf(stderr, "lock2\n"); > mtx.lock(); > fprintf(stderr, "unlock2\n"); > mtx.unlock(); > fprintf(stderr, "done\n"); > } > The problem can be reproduced only on musl-libc, the same binary > works well on the system with glibc. The same binary? Do you mean you have a glibc-built binary you're trying to use with musl? Or did you mean to say the same source program? > The problem does not reproduce each time, its reproducibility > depends on the phase of moon. > The problem can be reproduced more often it the code calling mutex > functions is located in the shared library. > > Strace (when the problem is reproduced): > [pid   709] writev(2, [{iov_base="-- testing gsMutex --\n", iov_len=22}, {iov_base=NULL, iov_len=0}], 2-- testing gsMutex -- > ) = 22 > [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="lock\n", iov_len=5}], 2lock > ) = 5 > [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock\n", iov_len=7}], 2unlock > ) = 7 > [pid   709] writev(2, [{iov_base="", iov_len=0}, {iov_base="lock2\n", iov_len=6}], 2lock2 > ) = 6 > [pid   709] futex(0x7f3a9733e4a4, FUTEX_WAIT_PRIVATE, 2147483664, NULL > > Strace (when the problem is not reproduced): > writev(2, [{iov_base="-- testing hhMutex --\n", iov_len=22}, {iov_base=NULL, iov_len=0}], 2-- testing hhMutex -- > ) = 22 > writev(2, [{iov_base="", iov_len=0}, {iov_base="lock\n", iov_len=5}], 2lock > ) = 5 > writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock\n", iov_len=7}], 2unlock > ) = 7 > writev(2, [{iov_base="", iov_len=0}, {iov_base="lock2\n", iov_len=6}], 2lock2 > ) = 6 > writev(2, [{iov_base="", iov_len=0}, {iov_base="unlock2\n", iov_len=8}], 2unlock2 > ) = 8 > writev(2, [{iov_base="", iov_len=0}, {iov_base="done\n", iov_len=5}], 2done > ) = 5 > > Thanks in advance for solving the problem. Can you post the full test case and information on how you built it, including what compiler you're using (whether it's from a distro, or one you built yourself, or what)? Rich