Date: Mon, 31 Dec 2007 15:18:45 -0800 From: Julian Elischer <julian@elischer.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: freebsd-hackers@freebsd.org, Markus Hoenicka <markus.hoenicka@mhoenicka.de> Subject: Re: dlopen(), atexit() crash on FreeBSD (testcase included) Message-ID: <477978D5.3000200@elischer.org> In-Reply-To: <20071231180605.1fb939a9@kan.dnsalias.net> References: <18297.6718.750894.937199@yeti.mininet> <20071231142620.39f2fbd2@kan.dnsalias.net> <18297.20596.564077.568365@yeti.mininet> <47796B43.9050704@elischer.org> <20071231180605.1fb939a9@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Kabaev wrote: > On Mon, 31 Dec 2007 14:20:51 -0800 > Julian Elischer <julian@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477978D5.3000200>