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

[Burlen Loring <burlen.loring@kitware.com>]

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@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
>   


-- 
Burlen Loring
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x137