Re: Problem with atexit and _dl_fini

["Nat!" <nat at mulle-kybernetik dot com>]

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!