Re: atexit, __cxa_atexit and __cxa_finalize interaction

[Florian Weimer <fweimer at redhat dot com>]

* Carlos O'Donell:

> On 6/11/19 3:06 PM, Adhemerval Zanella wrote:
>> Recently on libc-help [1], a user reported it observed some issues regarding
>> atexit order calling in some scenarios (callbacks were not issued in the 
>> expected order for some scenarios). After some time, he could provide an 
>> actual testcase that shows the issue he was referring [2].
>
> This issue has been around since the dawn of time.
>
> https://freebsd-arch.freebsd.narkive.com/zzyHX3Bw/dlclose-vs-atexit
>
> The options as outlined in the old FreeBSD discussion are informative.
>
> (1) Run atexit() at exit() after dlclose() and crash.
> (2) Run atexit() at dlclose() and try not to crash (impossible for the cyclic
>     case where two libraries call eachothers atexit functions i.e. no total
>     order possible, and we could detect this).

I don't think cyclic dependencies make this particularly difficult.  You
run the handlers first, and begin unmapping only afterwards.

> (3) Have atexit() increment the library ref count, and decrement it after
>     it runs during exit(), making the library unloadable (what SunOS does?)

The Solaris manual page says that atexit handlers run on DSO unload, I
think.

But at a high level, none of this has anything to do with the order in
which the atexit handlers are called by exit.  The example doesn't even
call dlclose.  If we get this wrong, it's the result of an inadvisable
shortcut taken in our implementation.  It's not really something that
follows from the required interactions between atext, dlopen and dlclose
due to unmapping, or anything like that.

Thanks,
Florian