[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240726195852.GO10433@brightrain.aerifal.cx>
Date: Fri, 26 Jul 2024 15:58:52 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com, libc-coord@...ts.openwall.com,
libc-alpha@...rceware.org
Subject: Re: Re: [libc-coord] Making exit actually thread-safe
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.
Rich
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.
