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 <lionelb.nospam@xxxxxxxxx> 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
--
Burlen Loring
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x137
