From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9960 invoked by alias); 9 Jul 2008 17:02:32 -0000 Received: (qmail 9952 invoked by uid 22791); 9 Jul 2008 17:02:30 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jul 2008 17:02:11 +0000 Received: by wr-out-0506.google.com with SMTP id c53so2158630wra.20 for ; Wed, 09 Jul 2008 10:02:08 -0700 (PDT) Received: by 10.90.63.12 with SMTP id l12mr8834747aga.5.1215622926698; Wed, 09 Jul 2008 10:02:06 -0700 (PDT) Received: from ?192.168.1.65? ( [66.194.253.20]) by mx.google.com with ESMTPS id p9sm9942831qbp.16.2008.07.09.10.02.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Jul 2008 10:02:06 -0700 (PDT) Message-ID: <4874EEEA.7030000@kitware.com> Date: Wed, 09 Jul 2008 18:08:00 -0000 From: Burlen Loring User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: James Gregory CC: Lionel B , gcc-help@gcc.gnu.org Subject: Re: Including affects whether or not program freezes? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00119.txt.bz2 Hi James, Including a header can affect the program somewhat.variables for instance might be placed in a different physical location due to slightly different executable size or optimization packing/aligning. This is the type of thing that you can see with using uninitialized variables. Also if you are running off the end of an array that was allocated on the stack(valgrind doesn't catch this as far as I know), you can see changes in behavior that come about with variations in the compile, because optimization sometimes packs and aligns data so that it ends up in a different spot relative to unoptimized build. With different memory used different bytes get trashed and hence the run time variability. Its often repeatable due to the fact that once the program runs it's likely to get loaded into the same physical memory each time it runs. Burlen James Gregory wrote: > On Wed, Jul 9, 2008 at 12:28 PM, Lionel B wrote: > >> On Wed, 09 Jul 2008 03:31:35 +0100, James Gregory wrote: >> >> >>> 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 >>> >> You give *way* too little information to even begin to guess what the >> problem might be... but this smells like a classic case of Undefined >> Behaviour - sometimes it appears to work, sometimes it doesn't. I.e. you >> have a bug in your program. >> > > Sure, I agree it is 99.999999% certain I am doing something wrong > hence the undefined behaviour. But doesn't it seem somewhat out of the > ordinary that the behaviour can be affected by which standard library > header files I include? How can this make a difference to the code > that gcc produces? It seems unlikely that it's a total coincidence > that whenever I run the version with iostream included it doesn't > freeze and whenever I run the version without it does (I just tried > recompiling the two versions again and the pattern holds). > > >>> Debugging this is difficult. >>> >> It frequently is ;-) but what other choice do you have? There are tools >> to help (debuggers such as gdb, memory leak checkers such as >> valgrind, ...) >> > > I have used gdb to see which function it freezes in, but as noted I > cannot compile with full debugging symbols and watch variables/step > through the code as this removes the bug. valgrind doesn't report any > problems at all (except a few warnings about functions called in > external libraries at start up). The reason I originally wanted to > include iostream was an effort to output the value of variables at > various points in the function which freezes, but as noted this also > removes the bug. > > >> First I would try stripping your program down to a minimal core that >> exhibits the buggy behaviour. Often in doing so you will isolate and >> identify the bug. If not seek help here or in a C (or C++, you don't say >> which language your program is in) forum. You can post minimal code >> demonstrating the problem. >> > > But if even including a certain header file can affect the behaviour, > how can I strip down the program except through random trial and > error? I guess what I'm trying to say is not "What is wrong with my > program?", when clearly I haven't given enough information for anyone > to help, but rather "Does anyone know what sort of thing might be > affected in the code gcc produces if I include iostream is included?". > > (And it is C++ not C, hence ) > > James > -- Burlen Loring Kitware, Inc. R&D Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x137