Re: Including <iostream> affects whether or not program freezes?

["James Gregory" <james.jrg@gmail.com>]

On Wed, Jul 9, 2008 at 12:28 PM, Lionel B <lionelb.nospam@gmail.com> 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 <iostream> 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 <iostream>)

James