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 5098 invoked from network); 21 Nov 2020 15:51:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2020 15:51:45 -0000 Received: (qmail 32192 invoked by uid 550); 21 Nov 2020 15:51:42 -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 32174 invoked from network); 21 Nov 2020 15:51:41 -0000 Date: Sat, 21 Nov 2020 10:51:29 -0500 From: Rich Felker To: a@saur0n.science Cc: musl@lists.openwall.com Message-ID: <20201121155128.GN534@brightrain.aerifal.cx> References: <1605849917.737458858@f540.i.mail.ru> <20201120055828.GL534@brightrain.aerifal.cx> <1605941217.735966206@f110.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1605941217.735966206@f110.i.mail.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Mutexes are not unlocking On Sat, Nov 21, 2020 at 09:46:57AM +0300, a@saur0n.science wrote: > Hello, > Thanks for the fast response. > > I compiled binary under OpenSUSE towards glibc and started on Alpine > Linux. I think you mean just compiled normally on OpenSUSE without doing anything related to musl at this point, but could you please conform that that's the case? Also, did you link libstdc++ statically or dynamically? Are you moving any additional shared libraries over from the glibc system, or just the application binary? Does it have any other libraries static linked into it? This is why I asked for full information on how you built it. The answers to these questions determine what direction you should look in. musl provides some minimal level of glibc-ABI-compat for attempting to get binaryware that you can't rebuild against musl to work. This doesn't mean building binaries for glibc and attempting to use them with musl is necessarily supported usage. It's possible that you're doing something that just can't work, but it's also possible that there are simple mistakes you could correct and get this working. > I think it is not a problem because mutex is aggregated by a > pointer. I'm also not clear exactly what you mean by that. > I am using gcc 10.2.1 20201028 [revision > a78cd759754c92cecbf235ac9b447dcdff6c6e2f] installed from OpenSUSE > reporitories. > > Unfortunately, I cannot post a "minimal working example", because > the bug does not reproduce on a small programs. This means the problem is in something you haven't shown or described. > This is the internal state of the mutex which caused problems at the > moment of second lock operation: > (gdb) print gsMutex > $1 = { = {_M_mutex = {__data = {__lock = 0, __count = 2147483664, __owner = 1, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { >          __prev = 0x0 , __next = 0x0 }}, __size = "\000\000\000\000\020\000\000\200\001", '\000' , __align = -9223371968135299072}}, } This is printing out a glibc data structure, which isn't going to be meaningful. Rich