[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
