Can redirection of screen output to file change the result of a C++ code?

Question

I am having this very weird behaviour with a C++ code: It gives me different results when running with and without redirecting the screen output to a file (reproducible in cygwin and linux). I mean, if I get the same executable and run it like ./run or run it like ./run >out.log, I get different results!

I use std::cout to output to screen, all lines ending with endl; I use ifstream for the input file; I use ofstream for output, all lines ending with endl.

I am using g++ 4.

Any idea what is going on?

UPDATE: I have hard-coded the input data, so 'ifstream' is not used, and problem persists.

UPDATE 2: That's getting interesting. I have probed three variables that are computed initially, and that's what I get when using with and without redirecting the output to file

redirected to file: 0 -0.02 0

direct to screen: 0 -0.02 1.04083e-17

So there's a round-off difference in the code variables with and without redirecting the output!

Now, why redirecting would interefere with an internal computation of the code?

UPDATE 3: If I redirect to /dev/null, I get the sam behaviour as outputing direct to screen, instead of redirecting to file.

Answer 1

There are a number of effects of running with nohup, but the main one is stdin and stdout will be redirected to /dev/null. In most cases, this means that stdout will be fully buffered instead of line buffered (its only line buffered if stdout is a terminal), so stuff that is output generally won't actually be output until you do an explicit flush.

Edit

Further updates make it unlikely the problem is directly related to the different behavior of nohup. At this point, I would suggest running with valgrind, as the most likely suspect is an uninitialized local variable or heap object. Such a variable will have an unpredictable (but generally repeatable) value that depends on the environment in which the function was invoked -- mostly on what previously called functions have left on the stack, which might well depend on nohup as you're seeing

Answer 2

Do you use threads in this application?

I've seen subtly different behaviour in a poorly synchronized threaded application on Linux with/without nohup, although I don't know whether this would have been reproduced with cygwin.

In my case, I had two initialization threads, but the order in which they completed was (mistakenly) significant. Without 'nohup' one would always complete first, but with 'nohup' the other generally would, I think the underlying cause was differences in IO buffering.