Date: Tue, 1 Jan 2008 10:40:18 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: freebsd-hackers@freebsd.org, Markus Hoenicka <markus.hoenicka@mhoenicka.de> Subject: Re: dlopen(), atexit() crash on FreeBSD (testcase included) Message-ID: <20080101104018.0fe51d67@kan.dnsalias.net> In-Reply-To: <4779AD03.1060505@freebsd.org> References: <18297.6718.750894.937199@yeti.mininet> <20071231142620.39f2fbd2@kan.dnsalias.net> <18297.20596.564077.568365@yeti.mininet> <4779AD03.1060505@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/py4gisGwkapcdZ84_msMOkv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 31 Dec 2007 19:01:23 -0800 Tim Kientzle <kientzle@freebsd.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. > > >=20 > >=20 > > That is, the only real solution to this problem is to convince the > > Firebird folks to remove their atexit() calls from the client > > libraries? >=20 > I suspect they never considered that their dynamic library > might be used via dlopen()/dlclose(). The real question is > whether they're interesting in supporting this model. > If the Firebird folks aren't interested in having their > library be accessible in that fashion, then you have > little choice but to simply forgo unloading this particular > library. >=20 > It's a bit unfortunate that there is no standard way > to remove an atexit() registration. It would probably > be easier to convince the Firebird folks to remove the > registration as part of their cleanup routines (and > you could then invoke those cleanup routines manually > for that case). >=20 > > 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. >=20 > I would be curious to see the results of running your > sample program (with lots of extra fprint(stderr...) > calls, of course) on Linux to see whether it calls the > registered exit function at dlclose time or never. >=20 Linux pulls hidden atexit symbol into every binary that uses it by means of linking in libc_nonshared.a into every glibc consumer. Having local function allows for reliable determination of who has called the atexit function. Linux calls atexit entries at object unload time. Solaris implements a libc callback from ld.so.1 to cleanup dangling pointers from objects being unloaded. This resets sigaction entries, atfork and atexit callbacks. Solaris calls atexit callback when removing it too. I guess we better follow the suit, if anyone wants to that. I prefer Solaris approach myself, but see the reason for Linux one too. --=20 Alexander Kabaev --Sig_/py4gisGwkapcdZ84_msMOkv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHel7iQ6z1jMm+XZYRApSYAKDQvld7nzJom/cJxM1aEX/EEpTEGACgtb4E htCiKwZa6bKLOSNr99KfPE0= =ziMS -----END PGP SIGNATURE----- --Sig_/py4gisGwkapcdZ84_msMOkv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080101104018.0fe51d67>