On Mon, 31 Dec 2007 14:20:51 -0800 Julian Elischer <[EMAIL PROTECTED]> 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. -- Alexander Kabaev
signature.asc
Description: PGP signature