From: "Nat!" <nat@mulle-kybernetik.com>
To: "libc-help@sourceware.org" <libc-help@sourceware.org>
Subject: Re: Problem with atexit and _dl_fini
Date: Wed, 22 May 2019 10:22:00 -0000 [thread overview]
Message-ID: <5CE522F8.9090505@mulle-kybernetik.com> (raw)
In-Reply-To: <115bdae5-bcd3-0e41-8325-784a0d702259@linaro.org>
Adhemerval Zanella schrieb:
>
> Could you provide a testcase that stress the issue you are seeing? At
> least on glibc it does have a testcase that does pretty much what you
> described, dlfcn/bug-atexit1-lib.c and dlfcn/bug-atexit1.c.
I tried to simplify it, but I failed and gave up (see below).
>
> It created a shared library with an exported symbol that registers at
> lot of atexit function and the main program dlopen and dclose it and
> checks if the atexit handlers are indeed called in the correct order.
> It does not use any C++, so there is no __cxa_finalize involved.
The use of __cxa_finalize is something I observed in my stacktrace
(see previous mails).
>
> Also, on your debug information I must confess it is confusing what
> exactly you are expecting and what exactly your program is doing.
> For instance I am not understanding the part 'I registered my two
> function with `__internal_atexit`'. Are you trying to calling it
> directly? Or are you calling __cxa_atexit? Keep in mind that
> __cxa_atexit calls are generated by compiler itself to destruct
> global objects.
>
I am really just using `atexit`. I was trying to explain, what the
internal glib problem is, that I observed setting breakpoints and
stepping through the code.
What conceptually I am doing is to install on-demand `atexit` handlers
during the load of shared libraries. These are then used for debugging.
Basically like this (typed by hand):
liba.so:
void a( void)
{
}
__attribute__((constructor))
static void check( void)
{
if( getenv( "DO_B_ON_EXIT"))
atexit( a);
}
libb.so:
void b( void)
{
}
__attribute__((constructor))
static void check( void)
{
if( getenv( "DO_A_ON_EXIT"))
atexit( b);
}
I tried this with a simple setup and that doesn't create problems as
such. But dl-fini re-sorts the dependencies sometimes, and then
the atexit order is compromised and that is what I am running into.
Ciao
Nat!
next prev parent reply other threads:[~2019-05-22 10:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-18 21:23 Nat!
2019-05-19 16:23 ` Florian Weimer
2019-05-19 19:37 ` Nat!
2019-05-21 20:43 ` Adhemerval Zanella
2019-05-22 10:22 ` Nat! [this message]
2019-05-22 15:01 ` Adhemerval Zanella
2019-05-22 15:29 ` Nat!
2019-05-22 19:35 ` Adhemerval Zanella
2019-05-29 21:16 ` Nat!
2019-06-09 20:59 ` Nat!
2019-06-10 11:48 ` Adhemerval Zanella
2019-06-10 13:08 ` Nat!
2019-06-10 20:27 ` Adhemerval Zanella
2019-06-11 18:39 ` Adhemerval Zanella
2019-06-11 20:20 ` Nat!
2019-06-11 22:40 ` Nat!
2019-06-12 3:41 ` Carlos O'Donell
2019-06-13 22:53 ` Nat!
2019-06-14 12:29 ` Manfred
2019-06-14 15:14 ` Adhemerval Zanella
2019-06-11 18:53 ` Nat!
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=5CE522F8.9090505@mulle-kybernetik.com \
--to=nat@mulle-kybernetik.com \
--cc=libc-help@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).