![]() |
|
Message-ID: <8e7aa290-1206-4758-9680-cb666979d3d7@redhat.com> Date: Fri, 26 Jul 2024 17:06:42 -0400 From: Carlos O'Donell <carlos@...hat.com> To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>, Markus Wichmann <nullplan@....net> Cc: libc-coord@...ts.openwall.com, libc-alpha@...rceware.org Subject: Re: [musl] Re: Making exit actually thread-safe On 7/26/24 3:58 PM, Rich Felker wrote: > On Fri, Jul 26, 2024 at 09:38:54PM +0200, Markus Wichmann wrote: >> 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. > > Yes. If we were going to allow recursive calls to exit, we would need > to either leave the case of call from dtor undefined, or add some > mechanism so that a call from a dtor did something predictable and > safe (like skipping all future dtors and going right to __stdio_exit, > or behaving like _exit, etc.) > > Short of having a way to define it that we've reasoned to be safe and > consistent, having it trap/abort seems the best course of action. I lean slightly towards trap/abort, but I don't think I can make that change today in glibc without breaking applications... even if the "skip subsequent destructors" case you mentioned upthread is poor behaviour. -- Cheers, Carlos.
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.