From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8E5242DA04 for ; Fri, 30 Aug 2024 17:07:52 +0200 (CEST) Received: (qmail 13454 invoked by uid 550); 30 Aug 2024 15:07:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13418 invoked from network); 30 Aug 2024 15:07:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1725030458; x=1725635258; i=nullplan@gmx.net; bh=HEAssFbA1aZC1sWEgHQnzs6QOrR38TEs6nmgYvvlL9o=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:In-Reply-To:Content-Transfer-Encoding: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=jkOpaMiHXgUuow/nxu6HvWW0IDWqaVFSSu6U7s87iCyWAhBIgcMuQ7oXle02MV+u 3FyTupk/soqBgTjO4NBy9U+cmMC+5IX+DjjsXtqWnvpxBjn6YAbOGot2N2VsrOFP8 v/P4fHCwZjTNSuInPnprHggyj3AEyQSDrRAFwgUYqL7TEO2u5vFhvzhstMhP7Wx2Z +WSQ3vUvPPVQdDxTlZj85rke+YAoSP5u5yM79KmqtEJya8VpRHRQYGoO3Yf76wZnb i5k64fi+68yPSHecQZWKPamvIGyHxZtYw/IBuhceO0QPkvJ1Uzw1IjA7AHN+jIHFu 3nPh2AMdetqqfqP5Jg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Fri, 30 Aug 2024 17:07:37 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: JinCheng Li Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:ofdDEQ2aRXpU6BSP3t4P8swb0it6G8ugUoNZ/1/wIEEOdvhGCRD GyVx2dIAAB9Wp7PdcIW7Put9KLXl7qDW8rL/w10mbk6P/NqHrS330COib/Iy9OD6RdAPjtm IFRDmeW05z/0xGaMajrzvPnCvs2LtLtSyksh2zMebP/K3lHIhgFtv4RAUf9l8nStCclvfch 2GPF5GrT/C07/T077vPhA== UI-OutboundReport: notjunk:1;M01:P0:IF78drhk6sY=;CPHy8MUCNQUt7X37lKG5qua9E6Y XUM5ZyW0AktWf+C+8EeHIo95OK5oItmGSAfvJ+oIlGBjO9qVUOVVsoemI3UaMazT6XOjaOUYO cbEnBeRQ62s9K8GqPuYcV4HM2+7hMViG/7U54RRmumvorko7wYTn3ZBpUnl5HbJY3HzupXU4p nYqBROrad+gxd9PGcZ+lMU+HQBV2D/SMb1QXCi8nNBaBHnkHyX7XpG9icHxa/8HiJMaPQ8OMV AUn3tWSm5cEg0LEI26aoeOQK+X8jd3mZy/vBp7lXUC5gMBCGdgmYpaPoEYk3t3ep7/4D0zRfU t4Rg2o9Stq5C99j9oUA1KM5HHmQgJ6gNzAZgjrZYPKNQsQd5LxboxtSSvGeC66dqZdIR0T5VY GlQA4eBRduGNt/bTSTXrfZNM84QIzZ9ic3uCVauDyUeio7Lltekr5NOKRiY2m1IVZyNVshr2v 4yI1WYWFOs/uuibAj7z7IZMSSYfo3mHlTN8i+1XRnqgmOaaAXOTfa6C86aDigyG5CXp8pOtHt AXp1PkEsntKzxkaL8/doxRLKoz29fS8nZyqiEarbvoESl4JWdrj+U+b92X6kj/L4jAdz62hmG MKl7hkCGhQVlEGX9jlyvyJnDqrRDUv4uciPqmN6yFdNUD/cCPFpdDCZB/CIAepOwaBqzCVnQg MWRL+SZTAoKEsb0mqodyv2LwA4m1EdwPYxfBTy6Z1BOgjWTWtMm1e7fXhKbxnSjguxVTfbrRq jtowq6kN8g7ntBwJ0YuH/xXPrVT7ZpMg/65hClQnzEKP0ckZDHjk7o18ozj08uzNpF689CX/g 2zXzbCWcfAOrAMvRqQllJT8ST18DjvNc9VHuHKl3jo5U0= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Question about the exit() Am Fri, Aug 30, 2024 at 01:34:58PM +0000 schrieb JinCheng Li: > Hi > > I have one question in exit(). > Why is the __libc_exit_fini executed after __funcs_on_exit? If some > finalized functions in .fini_array access global variables which is > registered by __cxa_atexit and will be release in __funcs_on_exit, we > may run into some crash during __libc_exit_fini executaion. > POSIX does not require an ordering between atexit handlers and destructors. Since the order is unspecified, an application requiring a specific order is broken and must be fixed. Notice that atexit() is the better mechanism here, since with it you can even select the order in which the destructors run (they run in reverse order of registration). With normal destructors, the order is again unspecified. > In bionic, I found the fini_array functions may be registered at the > last before we execute main function and called firstly in exit(before > global variables release) . Its order looks like completely opposite > to musl. > You probably missed the part where __cxa_finalize() calls all handlers in reverse order. The first handler registered is the last handler executed. Thus, in bionic as well, the application's atexit handlers run first, followed by the destructors. Also, according to enh, android rarely has applications exit. They typically run until killed. So it is also likely that that code is not well tested. Ciao, Markus