Re: [musl] Hung processes with althttpd web server

[Markus Wichmann <nullplan@gmx.net>]

Am Thu, Oct 05, 2023 at 02:26:42PM -0400 schrieb Carl Chave:
> #5  0x00007f5fb449d7c0 in __pthread_mutex_lock
> (m=m@entry=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