From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32357 invoked by alias); 9 Jul 2008 16:49:43 -0000 Received: (qmail 32348 invoked by uid 22791); 9 Jul 2008 16:49:42 -0000 X-Spam-Check-By: sourceware.org Received: from wf-out-1314.google.com (HELO wf-out-1314.google.com) (209.85.200.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jul 2008 16:49:22 +0000 Received: by wf-out-1314.google.com with SMTP id 25so3138621wfc.14 for ; Wed, 09 Jul 2008 09:49:19 -0700 (PDT) Received: by 10.142.187.8 with SMTP id k8mr2355984wff.199.1215622159754; Wed, 09 Jul 2008 09:49:19 -0700 (PDT) Received: by 10.142.89.5 with HTTP; Wed, 9 Jul 2008 09:49:19 -0700 (PDT) Message-ID: <5cc6b04e0807090949g30d5aacckc170e6068093e5a4@mail.gmail.com> Date: Wed, 09 Jul 2008 17:02:00 -0000 From: "Chris Jefferson" To: "James Gregory" Subject: Re: Including affects whether or not program freezes? Cc: gcc-help@gcc.gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg00118.txt.bz2 2008/7/9 James Gregory : > 1. Compile with MSVC 7.1, no optimization: my program doesn't freeze > 2. Compile with MSVC 7.1, with optimization: my program doesn't freeze > 3. Compile with gcc 4.2.3 (Ubuntu 64 bit), no optimization: my program > doesn't freeze > 4. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization: my > program freezes in a particular function > 5. Compile with gcc 4.2.3 (Ubuntu 64 bit), with optimization, and > include at the top of the file where the function which > freezes is defined: my program doesn't freeze > > Debugging this is difficult. While I could well be repeating what others say, my usual tools for situations like this, which (touch wood) tend to get me out of it: A) Turn on all warnings, and read what they say. I've found this kind of thing can be caused by a missing return statement. B) Turn on the debugging standard library, if you are using any of the STL in your code. C) Find the minimial set of optimisation flags you need to trigger your problem (in particular if you can turn off inlining it will make things easier). This makes the next stage easier. D) Use valgrind and see what it comes up with. The problem sounds to me like your problem could well be triggered by inlining, which is often very sensitive (at least in g++) and can change from headers being included on occasion. > > James >