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 2524 invoked from network); 5 Oct 2023 18:48:41 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Oct 2023 18:48:41 -0000 Received: (qmail 30624 invoked by uid 550); 5 Oct 2023 18:48: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 30592 invoked from network); 5 Oct 2023 18:48:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1696531705; x=1697136505; i=nullplan@gmx.net; bh=Tncuk+Oj9FH5HuR0OLAZn9fKlKW50f5c9uA+9GiOals=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=a5i0odJoGsZ5XsrNZLBC+vS/76mzZjkWkW94U5XX7JiqtYCEgILj/ndo88BqXTFh3k5maLhized Os2W2XIXrkpWQjIdcE2BhQmaQumeImCroYEkqaYmCxjdQSBMCVWz8boD86lIcSjaZF9YJ7nXppHM+ lUjPQ8tp3GyrhOY87WrFra6EdQhm9ACGp0PufGChpuFdXGIij4CuscsN4AJNzG7kCOd0IXnDYWGDR EjaTiqNC2pkZ2FBGKy1eRjaQLD+JiZ4SWMmrSaeEHv616DhS20/92jngLy+fS1eEoYdA1eqKS7hMC wuBX2RjJXt4Lt54AdnXIWqkNUAQ6vOVSLCRQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 5 Oct 2023 20:48:23 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Carl Chave , Rich Felker , musl@lists.openwall.com Message-ID: References: <20231005021539.GG4163@brightrain.aerifal.cx> <20231005133926.GC1427497@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:ZkR9UVYnbUnvFcukn5VGehsqQZrYTYwuAa9u+aS+C9m/ZAi0nnF jEQrw80oGYXUwGHEoR8Zr+ccV4nD+8p53Ynjwxt3TMhDaT50xi++mV+r0UsnqjvClJg2y+B 361txp8axz5O07L8FxMEiPsbRQhdC9RPtVC/TB9BpW64J93Gji7IjXpdJBTlUgUtFuGDJxq 9L0Y87/LFjHYgJTwRyZJg== UI-OutboundReport: notjunk:1;M01:P0:Yp68LSGpq8U=;LtS7ZXXt5d0gDXg/Fc4OEPPLZX+ AEgMAPigOKwtWMMDdgTTGzkJ/nXxDO66lsWo2yAQZl8ifjQUg50mfJefQUj7tDjMteBwK71dv Zqi2XMLwzsWKEfGfCDzbtDOgVdk2+LcAJCuYULKan194hYYxN2P/YInH9U8MlU+obExwn7W99 JHUoyit6g0HbCARDoGRMtVW07Ss4EGlmJtVOdXC554OsdReCo4b2m/UjPlyiovfnoVplhDB9T nF1OgsZ2hQm9Qkm8BUJw0q8f9uxVKBDXLFU6LvKAnuPw4xYy6jcLVkkzbwl+6Oh7bzRd3xXt2 8r8EJCj40hHDGAdzH5kozU/UGRChr7K3X0736nb/vhWyqWa4kcoescuXVEhXDJxvq3agKmqpd mZO/9HFacSZAsbjk+8CznQNI7sscB4Jia07AuX4B3o333NiNHiW5yfs2ahVESqdnFfXdW4w0j BnRTLgAdy9iVHQzTTJCr0N+EwbbdYPPeiTsP5JfHzS1OMEL03Fx7ntgkD64J3x9FocejBlg/p ULSY2+gUbEob44294jjGPjU2zRLpPnDEG9F4ndZwaCxMDfNTSArftdW34XtLOmZcaLZWCCaQO 98510Wzxxao0IpwUvabc7dwXaEgOEJH5mW/IbfrWTuQ8y3fvwI+73+sM4Dd1Y5x1UWUytgqMa +9Bm9+Eqqlp8V+VFrBXfNnVz1ROR92EtCfl4e2H062ihdAljVjIkMvwZklBzE1ccqkoxf0BO7 PY4UlE7QzEMXhtsa+egERg2OrLjbRrGZLhEdgW79RMUBZUDXldvfQ+1v/NgFx38yMEe7t5Qj9 cDEp8WxEWlw3FTul/CZQ7f2hS8sp2Gf3r10e59PK1RTs8xYukv839zP0MkAFzxIjBRQMZ6bsN KEQ6nOTI2M2kQdweFrZIEtn4gaI2YYWTVBRdYNYW6SScivp3Fn65t9VVmm8IEguNTXejnBSOV enXyLd6WF+JDBguQmHG0KVEtP2o= Subject: Re: [musl] Hung processes with althttpd web server Am Thu, Oct 05, 2023 at 02:26:42PM -0400 schrieb Carl Chave: > #5 0x00007f5fb449d7c0 in __pthread_mutex_lock > (m=m@entry=0x7f5fb44e0880 ) at > src/thread/pthread_mutex_lock.c:9 > #6 0x00007f5fb44a49ff in __libc_exit_fini () at ldso/dynlink.c:1442 > #7 0x00007f5fb445b082 in exit (code=0) at src/exit/exit.c:30 > #8 0x0000557471c3cf45 in ?? () > #9 > #10 0x00007f5fb43d3f20 in ?? () from /lib/libssl.so.3 > #11 0x00007f5fb44a4a9d in __libc_exit_fini () at ldso/dynlink.c:1453 > #12 0x00007f5fb445b082 in exit (code=0) at src/exit/exit.c:30 Oh, goddang it, I had just theorized that. The process is actually finished and called exit(). exit() has in turn called __libc_exit_fini(), which has taken the init_fini_lock and is now calling the destructors. Apparently libssl has a destructor, and while it is running the signal hits. And then the signal handler also calls exit() (which is invalid, for exit() is not signal-safe), and tries to call __libc_exit_fini() again, and that deadlocks on init_fini_lock. But that also means that you sometimes get the other deadlock I theorized in my other mail just now, the deadlock on "lock" in dynlink.c. Because this backtrace does not fit the strace from earlier. Solution is still the same as before: Either clean up the signal handler or don't even register it in the first place. The proper place to log unusual exit of a process is in the parent process. All of the intercepted signals have a default action of Term or Core, so they will cause the end of the process. Ciao, Markus