Date: Thu, 5 Oct 2023 20:34:03 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: 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
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.