From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 31 22:35:39 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F84716A417 for ; Mon, 31 Dec 2007 22:35:39 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id BE89D13C457 for ; Mon, 31 Dec 2007 22:35:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226848344-1834499 for multiple; Mon, 31 Dec 2007 17:35:35 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBVMZZel099982; Mon, 31 Dec 2007 17:35:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 31 Dec 2007 17:35:42 -0500 User-Agent: KMail/1.9.6 References: <18297.6718.750894.937199@yeti.mininet> <18297.20596.564077.568365@yeti.mininet> <47796B43.9050704@elischer.org> In-Reply-To: <47796B43.9050704@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712311735.43320.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 31 Dec 2007 17:35:35 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5314/Mon Dec 31 16:46:09 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Julian Elischer , Markus Hoenicka Subject: Re: dlopen(), atexit() crash on FreeBSD (testcase included) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2007 22:35:39 -0000 On Monday 31 December 2007 05:20:51 pm Julian Elischer 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. Older gcc used to use atexit() for destructors (2.95.x for example) but newer versions of gcc use fini routines. We have a hack in the run time linker that walks the atexit() list for 4.x binaries and manually pulls out any routines in the mapped region of a shared object during dlclose() to invoke the destructors and fixup the atexit list. However, newer binaries don't need this. If you used a regular old static C++ singleton on 6.x instead of trying to be cute and call atexit() directly you would be fine. I've no idea if Linux treats atexit() special. The documentation below for atexit() is very clear that handlers are only invoked for normal program termination, not for dlclose(), so you definitely have buggy code. http://www.opengroup.org/onlinepubs/009695399/functions/atexit.html -- John Baldwin