![]() |
|
Message-ID: <ZqP7TthiCuj44Vx-@voyager> Date: Fri, 26 Jul 2024 21:38:54 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Cc: libc-coord@...ts.openwall.com, libc-alpha@...rceware.org Subject: Re: Re: [libc-coord] Making exit actually thread-safe Am Thu, Jul 25, 2024 at 08:39:27AM -0400 schrieb enh: > aye, but a program that calls exit() from an atexit() handler is > working for me right now on Android, glibc, and macOS. so there's a > user-visible behavior change here for any of those libcs that goes > with a non-recursive mutex. (i think the same is true for musl too, > but don't have a musl-based system to test on.) For musl, calling exit() from an atexit handler will work somewhat normally, at the moment. __funcs_on_exit() can be called re-entrant from a handler without a problem. I think that was mainly to enable calls to atexit() from atexit handlers (whatever sense that makes), but a side effect is that calling exit() should also work. Also note that calling exit() from a destructor (_fini() or DT_FINI or such like) has significantly more adverse effects. In the dynamic linking case, it reliably leads to a deadlock on the init_fini_lock. In the static linking case, it leads to a re-entrant call to libc_exit_fini(), which will call the same destructor again. Unless the destructor took measures to prevent this, this will lead to infinite recursion, and finally a process crash. 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.