From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22203 invoked by alias); 9 Jul 2008 16:22:57 -0000 Received: (qmail 22194 invoked by uid 22791); 9 Jul 2008 16:22:56 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jul 2008 16:22:37 +0000 Received: by fg-out-1718.google.com with SMTP id e21so1229973fga.28 for ; Wed, 09 Jul 2008 09:22:34 -0700 (PDT) Received: by 10.86.95.20 with SMTP id s20mr7220007fgb.62.1215620554426; Wed, 09 Jul 2008 09:22:34 -0700 (PDT) Received: by 10.86.66.18 with HTTP; Wed, 9 Jul 2008 09:22:34 -0700 (PDT) Message-ID: Date: Wed, 09 Jul 2008 16:49:00 -0000 From: "James Gregory" To: "Lionel B" 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/msg00117.txt.bz2 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