Date: Thu, 5 Oct 2023 20:48:23 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: Carl Chave <online@...ve.us>, Rich Felker <dalias@...c.org>, musl@...ts.openwall.com Subject: Re: 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@...ry=0x7f5fb44e0880 <init_fini_lock>) 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 <signal handler called> > #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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.