From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id 1D3543858402 for ; Thu, 9 Dec 2021 13:35:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D3543858402 Received: by mail-ed1-x531.google.com with SMTP id v1so19795350edx.2 for ; Thu, 09 Dec 2021 05:35:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eRoWWa5HSvAJ3n/Xy/1oyhaQS6pxhWcLrnb6ntqtAsI=; b=E4toboZtDkdRUUBQA5tixmvS6cNVckSJY+3TeS/dPATDRuhDVjFOGWPyNenv9sWL8q 1y9HM8iFZnEhDhtM/4Lj+S6mIsiWIlzWykPPhotmcIlAgRUIXP6g4g6oz35cz4OnIJZO Hk17yX1SBEbBIcJvnu+gNnS66t52oaR1qjdjdTv2AtUgNbslX8M8GUDldPq9bwgNaEIk EiuDifiZ3Y/6Ze/qzNBfEGLvuMunoZKFV151PqKS74POdAdLcUaw1vLyuy+cP0oEkov2 inaqquKc0w9XQCK/bEU2ks4mah6nwk8CV8d4l5q67Bva2hMzC+GW2Z+ueg+/kOnLT6MI U02A== X-Gm-Message-State: AOAM530nxJbg6XiajOKul+QGpdM/fCMzXdS2rJY3JlTxiUr5vmSGSgBj NhmO/lZJMs9gL3nzQriqCvwrg6BBhkY+sdX9gFV4SrFHmBs= X-Google-Smtp-Source: ABdhPJwYJCigPqMeiv5ZE4f2zZ7ig3REpfYsW4fobyncWJB4OYG2JXjbXDPc2G5D8MkjE3sWJ+9G382daknC1Ton0CU= X-Received: by 2002:a17:907:7ba4:: with SMTP id ne36mr15691721ejc.227.1639056928725; Thu, 09 Dec 2021 05:35:28 -0800 (PST) MIME-Version: 1.0 From: Boris Ouretskey Date: Thu, 9 Dec 2021 15:35:17 +0200 Message-ID: Subject: Destruction order of function static members of different translation units To: libc-help@sourceware.org X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 13:35:31 -0000 Hi, I have seen some information on the mailing lists and forums but nothing really focused. Not sure also if the question is for the libc community or gcc . The situation we are dealing with is the "destruction fiasco". Because of heavily templated code and many SO(DLL) translation units, which are using common template headers, there are some static storage interdependencies between functions' static members of different SO. For example:- ---- common_header,h ---- template struct A { void do {}; static A* Instance() { static A* m_instance; ... // create m_instance if null return m_instance; } } ---- translation_unit1.cpp (tu1) --> compiled into tu1.so ---- #include "common_header,h" foo() { A<1>::Instance()->do(); A<2>::Instance()->do(); } ---- translation_unit2.cpp (tu2) --> compiled into a.out executable and links tu1.so ----- #include "common_header,h" bar() { A<1>::Instance()->do(); A<2>::Instance()->do(); } What happens in our code is that A<1> ::m_instance is defined in tu1, and A<2> ::m_instance is defined in tu2. Eventually, the program crashes on exit, because the code in the main module is trying to destruct a static member (say A<2> ::m_instance) which is using an already destructed global member of tu1 which was already destroyed before (and unloaded probably?). I found some answers on the internet telling that destruction order between different TU is undefined in general. What is confusing me is that in our case only one object destruction is out of order so probably gcc/libc does some effort to keep it in order. Only one objects' destruction is postponed for some reason till the end instead of being dealt with in a "natural" reverse creation order. and this is the exact object which causes the trouble. The questions will be:- - Is gcc/libc trying their best to keep the creation and destruction order even between static objects defined in different translation units or none effort is taken and only order in single TU is preserved? - If the answer of the previous question is yes then what can cause changing the order of destruction? So maybe we can dapat our code to not crash on exit.