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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 1914 invoked from network); 5 Oct 2023 18:34:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Oct 2023 18:34:19 -0000 Received: (qmail 15536 invoked by uid 550); 5 Oct 2023 18:34:16 -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 15452 invoked from network); 5 Oct 2023 18:34:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1696530844; x=1697135644; i=nullplan@gmx.net; bh=1YrxfUNad7hUhYq42l70boG3GydJ86f6bl3+mrqoyFk=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=qoAPffSsbsr8iTIOQkTpZCkQ2DMWFvV5aYZzTe9fRZdWtLINAinBpvr26VMtzx69rqrmhpk9CS2 rV6Vmc+6vyFqWIwRov9heOyK1XCJaTjYTwEklTh5OALaUOySzXcjll/7tfwsLMS060AfQPlL++Ral dj/QoplntqGN0j3U5Hyey5p+68ObDEmUkJWL58scpbHplvHAXjz8m51nYOq8iElzEh2uoc03gjJPG as7YtK3ospjy1rqXhFX0hI0vkL08Kkvgrz7Bd9EruBaacMzaeK44419lRr1WzS9qwdEXhf//j9QUo N3QN/cN9cXmZHAZheOewLfmf+NhT03JosBJA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 5 Oct 2023 20:34:03 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: References: <20231005123858.GH4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231005123858.GH4163@brightrain.aerifal.cx> X-Provags-ID: V03:K1:LNkjXwVU0kyuwR3W/eW04CgFG74vTB1aZ2L6VGEdaZxYwDHAzsw 0QMGPikJyy+521A9wGQGr6Gb0OA8lak7oHviTfVqRlNU1WqhVDQtU2X6HAnd3n9eeaOrK0+ IzbRVAkkj3IlmBnzP61fYIQg6xk0QQ2Q0tqpcZAVyBZfYlmtqGp9S2aGUYUVFxfGTgfNxcb gFxK9QRNXfIYv0L0WLkNw== UI-OutboundReport: notjunk:1;M01:P0:/Noq64obq3I=;vVZpt6sTd0IRs7g/6H6eHlEzhzK hZfGhYJ3agAJ873NBwWqynERO2hd/S7SUa3ITcPqJeT3CfryZ7CEyCVT1pvXvZdjPwiuce8TZ 022pZn294F2cwsqYqWuAMAK+261fZxQJoXSuukFmuM/XruQMMrvX9rbSUC8FdYHmRMN3qoplz u3zVRTclBJnwq+YDHR7jDdU6SZPKRAi7650b1nXEZ+6gIWdZmzMAG86PSxxm3geptDzMut2ug vEoGfbd3Al4aCTLLNitd33B9QOkRLgI7gBGVgmzYBR6LQpopLMVfYt2ldJ6eQkYW23bFjiN8Y bmCZUXA0HU0vF2X1XTEL4OlU1o4zKt85K3VuEuTbAEAANZjmjw5GGW8CoSP+EnUokquA3uj2V z079Tfc2UayMkTa4T1OOM1xLtOEMp+wMFAHkNNPKcFVG667bmcf8AwWyLMvfz/5o/lYjdCjos JVa13boMMuGdFfro4RY50uCE2X4SULFKxLx11oHcSy9/ldVAsDQ+CDRSb2YV8+ixu9mVJtApQ 9SN0CREActOC6T4vnsRrZwkAZ2RwxvaOQy5amMzbFFw5WhNriQvCuWbTW6o7+MlwOdgoSpwOE axLqNXimpWR6Z5Zq+UHWwwuMNmIVp+Fgbd8cbMkoPopWA9VVSZdtAzQf4+JUIILgq1isX46WG MJzbv/BqiMkqF/7ybYrd3M0BgTYkMV2LbrTsvbCJ1wmE2EOLAW+2IHV7gJJvx0k9VNsZf/NSp /VWb59Mz6mXJn/TIvHRbOYJywFQua4xw7e5rN1DY0TngCFTTaKCC7gU8wFCXzgJX1rcsibMYO +O3oFzFt0w/MVZHF0lL9t1+Rdniud5CHH6iLsrB4zMq+MGzJpOK3uYgbCkscdFiwkyL65om59 gGjTuq4n7HkvKXCmkN5Y+QyoTZqhQERqo0DHwb3RCGGqEt5rZ3shZIfj81Jj2OSuPstkVKb8W Xuv3fQ== Subject: Re: [musl] Hung processes with althttpd web server Am Thu, Oct 05, 2023 at 08:39:03AM -0400 schrieb Rich Felker: > > Am Wed, Oct 04, 2023 at 09:41:41PM -0400 schrieb Carl Chave: > > > futex(0x7f5bdcd77900, FUTEX_WAIT_PRIVATE, 4294967295, NULL > It would still be > interesting to know which lock is being hit here, since for the most > part, locks are skipped in single-threaded processes. The only hints to that we have right now are the futex address and value. The address looks like it would be in some mmap()ed memory, but that could be anything. The value is more interesting. Because it shows us that the object is set to 0xffffffff when taken by a thread and a single waiter is present. And the only synchronization object I could find that does that is pthread_rwlock_t. There would also be sem_t for older musl versions, but since the wait flag overhaul it isn't anymore, and that was last year. I know that musl has some internal rwlocks, but the only one I could find that would plausibly be locked in write mode is the lock in dynlink.c, which is wrlocked in __libc_exit_fini(), among other places. Of course, the signal handler in althttpd also calls exit(), which may reach there. So it might be that the signal hit while the code was trying to exit, leading to a re-entrant call to exit(), and therefore to a deadlock. So that's possible. But the time the lock is taken in __libc_exit_fini() is so small, this theory seems like a reach. There is also __inhibit_ptc(), but I could find nothing that would call that in a single-threaded process. Let alone twice. Ciao, Markus