Alexander Kabaev wrote:
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.
Yes.. I wasn't saying it was a good idea, just that it may be
something that the linux folks might have done.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
