From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14106 invoked by alias); 22 Sep 2003 11:48:21 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 14078 invoked from network); 22 Sep 2003 11:48:17 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 22 Sep 2003 11:48:17 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.20) id 1A1PAY-0005af-DE for gcc-help@gnu.org; Mon, 22 Sep 2003 07:47:54 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.22) id 1A1PAo-0006tX-FY for gcc-help@gnu.org; Mon, 22 Sep 2003 07:48:11 -0400 Received: from [158.140.2.1] (helo=mailgate.Cadence.COM) by monty-python.gnu.org with esmtp (Exim 4.22) id 1A1P9X-0006T5-FF for gcc-help@gnu.org; Mon, 22 Sep 2003 07:46:51 -0400 Received: from cdsmunich.Cadence.COM (cdsmunich.Cadence.COM [158.140.172.1]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id EAA21816; Mon, 22 Sep 2003 04:46:48 -0700 (PDT) Received: from pciogheri2 ([158.140.211.118]) by cdsmunich.Cadence.COM (8.10.1/8.8.5) with ESMTP id h8MBkl804937; Mon, 22 Sep 2003 13:46:47 +0200 (MET DST) From: "ogheri" To: "'Eljay Love-Jensen'" , Subject: RE: Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris Date: Mon, 22 Sep 2003 11:48:00 -0000 Message-ID: <000001c380ff$33e61b80$76d38c9e@global.cadence.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-reply-to: <5.2.1.1.0.20030922062920.00bc95e8@iplan-mn.corp.adobe.com> Importance: Normal X-Received: By mailgate.Cadence.COM as EAA21816 at Mon Sep 22 04:46:48 2003 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,ORIGINAL_MESSAGE version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2003-09/txt/msg00254.txt.bz2 Hi Eljay, Thanks a lot for helping me! This is also what I told the customer. Actually, the C++ standard tells that the order of construction is the order in which the global objects appear inside of a single translation unit (a .cpp file). What is not sure is in which order global objects coming from multiple source files (and therefore multiple object files) are created (and then destructed!). My basic question was more focused on asking if someone ever had such problems with gcc showing that gcc 2.95.3 for solaris HAS A BUG IN THE DESTRUCTOR CALLING MECHANISM FOR STATIC OBJECTS: actually I don't think so! I suspect the code of the customer does exactly what you describe, and that's why they incur in the problem. Please give me only some other days to get an answer from them and confirm you if this was the case. Rgds, Ogheri Alessandro Senior Support AE LDV Area Cadence Design Systems GmbH MozartStrasse 2 85622 Feldkirchen Tel +49 (0)89 4563 1866 Tel +49 (0)172 1404451 -----Original Message----- From: Eljay Love-Jensen [mailto:eljay@adobe.com] Sent: Monday, September 22, 2003 1:35 PM To: ogheri; gcc-help@gnu.org Subject: Re: Need some help for troubles with the chain of destructors called for static (global) objects in g++ 2.95.3 for solaris Hi Ogheri, My bet is that this is an order-of-destruction problem. They usually occur when one static or global object refers to and relies upon another static or global object during its destruction (as the program is shutting down), but the other object has already been destructed. If that is the problem, to solve order-of-destruction problems, interrelationships between global objects needs to be scrutinized. Keep in mind, order of construction and order of destruction is not something to rely upon in C or C++! One way that worked for me to get rid of all order-of-destruction problems was to eliminate ALL global objects (global "plain old data" types are usually okay... but I got rid of them too). Another way to help track down order-of-destruction issues is to make sure each object sets all it's data members to some known garbage value (don't use memset ... set each field explicitly). Of course, you'll need the source code to effect these kinds of changes. HTH, --Eljay