From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 784 invoked by alias); 19 May 2019 16:23:24 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 773 invoked by uid 89); 19 May 2019 16:23:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1105 X-HELO: albireo.enyo.de Received: from albireo.enyo.de (HELO albireo.enyo.de) (5.158.152.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 May 2019 16:23:23 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hSOam-0007LC-VU; Sun, 19 May 2019 16:23:20 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1hSOam-0007Bl-Pc; Sun, 19 May 2019 18:23:20 +0200 From: Florian Weimer To: Nat! Cc: libc-help@sourceware.org Subject: Re: Problem with atexit and _dl_fini References: Date: Sun, 19 May 2019 16:23:00 -0000 In-Reply-To: (Nat!'s message of "Sat, 18 May 2019 23:23:23 +0200") Message-ID: <87blzypg5j.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00027.txt.bz2 * Nat!: > So my problem is, that I observe that my atexit calls are not executed=20 > in the correct order. > > i.e. atexit( a); atexit( b);=A0 should result in b(), a() being called in= =20 > that order. To quote the man page, > > "the registered functions are invoked in reverse order". > > > When I register with `atexit` I can see my functions being added=20 > properly within `__internal_atexit` in the > > correct order. Finally after my functions, the elf-loader ? also adds=20 > itself there. So it is being called first by > > `__run_exit_handlers`. > > > Then comes the part where it goes wrong. I registered my two function=20 > with `__internal_atexit`, but for some reason > > `_dl_fini` is calling `__cxa_finalize` and that is calling the wrong=20 > function first. When atexit is called from a DSO, glibc calls the registered function before the DSO is unloaded. This choice was made because after unloading, the function pointer becomes invalid. I haven't checked, but I suspect atexit still works this way even if it doesn't have to (because the DSO is never unloaded).