mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: JinCheng Li <naiveli233@outlook.com>
Subject: Re: [musl] Question about the exit()
Date: Fri, 30 Aug 2024 17:07:37 +0200	[thread overview]
Message-ID: <ZtHgOaH19Hmd23uh@voyager> (raw)
In-Reply-To: <SE1P216MB24840DB4017D42E4B93198C59E972@SE1P216MB2484.KORP216.PROD.OUTLOOK.COM>

Am Fri, Aug 30, 2024 at 01:34:58PM +0000 schrieb JinCheng Li:
> Hi
>
> I have one question in exit().
> Why is the __libc_exit_fini executed after __funcs_on_exit?  If some
> finalized functions in .fini_array access global variables which is
> registered by __cxa_atexit and will be release in __funcs_on_exit, we
> may run into some crash during __libc_exit_fini executaion.
>

POSIX does not require an ordering between atexit handlers and
destructors. Since the order is unspecified, an application requiring a
specific order is broken and must be fixed. Notice that atexit() is the
better mechanism here, since with it you can even select the order in
which the destructors run (they run in reverse order of registration).
With normal destructors, the order is again unspecified.

> In bionic, I found the fini_array functions may be registered at the
> last before we execute main function and called firstly in exit(before
> global variables release) . Its order looks like completely opposite
> to musl.
>

You probably missed the part where __cxa_finalize() calls all handlers
in reverse order. The first handler registered is the last handler
executed. Thus, in bionic as well, the application's atexit handlers run
first, followed by the destructors.

Also, according to enh, android rarely has applications exit. They
typically run until killed. So it is also likely that that code is not
well tested.

Ciao,
Markus

  reply	other threads:[~2024-08-30 15:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30 13:34 JinCheng Li
2024-08-30 15:07 ` Markus Wichmann [this message]
2024-08-30 15:08 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZtHgOaH19Hmd23uh@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    --cc=naiveli233@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).