dlopen(), atexit() crash on FreeBSD (testcase included)

[Julian Elischer]

Alexander Kabaev wrote:
> On Mon, 31 Dec 2007 14:20:51 -0800
> Julian Elischer <julian at elischer.org> wrote:
> 
>> Markus Hoenicka wrote:
>>> Alexander Kabaev writes:
>>>  > As designed. atexit should not be used by shared objects that do
>>>  > not expect themselves to live until actual exit() happens. ELF
>>>  > provides proper _init/_fini sections to support shared object
>>>  > initialization/destruction.
>>>  > 
>>>
>>> That is, the only real solution to this problem is to convince the
>>> Firebird folks to remove their atexit() calls from the client
>>> libraries? I'll try, but I'm not very confident this is going to
>>> work. Also, I'm wondering how other OSes handle this. I don't see
>>> this code crash on Linux, contrary to its design as you say.
>>>
>>> Thanks anyway to you, and to Jason Evans, for your replies.
>> Not sure but I'd guess that each library calls its at_exit entrypoints
>> as part of its unload handling.
>>
>    This is not possible in general case. The object that calls atexit()
> is not necessarily object that contains clean-up routine, so when
> atexit() is to be called: when object that contains the routine itself
> is being unloaded or when the object that registered it goes away? Also,
> calling atexit hooks at that time is semantically wrong for atexit() as
> it is defined, dlclose(3) is NOT exit(2). C++ ABI defines a special
> __cxa_atexit function that does have proper semantics to work around
> atexit() deficiencies.
> 
> We can hack rtld/libc to pull dangling atexit off the list entries when
> shared objects are being unloaded or to add extra references to
> libraries pointed to by atexit entries, but that will just paper over
> the general issue of Firebird (and like) folks using the API improperly.
> 

Yes.. I wasn't saying it was a good idea, just that it may be
something that the linux folks might have done.