I have an C++ application program that is producing incorrect results
but the error goes away when I run it through the debugger.

I'm using the gcc/g++ compiler under Cygwin (an UNIX emulator that
runs on windows).

When I used the -ggdb compiler flag so I can run it under the gdb
debugger, the error goes away.  It also runs fine if I do both of the
following; extract a few of the input instances which generate
incorrect results and put them in a separate input file.
Use this input file and recompile the program with no optimization
flags (I am otherwise using the -O3 optimization flag).

The -O3 optimizations are supposed to always produce the same
results.  Running through the debugger is not supposed to change the
results either.  Has anybody else encountered this behavior?
[The usual problem is that you're doing something that isn't valid
C, so the optimizer doesn't preserve its semantics. -John]

      When I was working, and people came to me with this sort of
problem, I developed a conditioned reflex to ask, "Are you sure you're
not using an uninitialised variable somewhere?".  I'm not saying that it
definitely *is* this (our esteemed moderator points out that it could be
anything not valid in C); but it's well worth checking IME.

      Hope this is useful!
      Mark

rhoads@cs.rutgers.edu <rhoads@cs.rutgers.edu>
>I have an C++ application program that is producing incorrect results
>but the error goes away when I run it through the debugger.

A typical cause of such behaviour is that something in the executable
is being destroyed.  Modifying the code in some way such as removing
or adding a print statement, etc, alters the effect.

Likely causes are a subscript error, or string error,
but is not restricted to those; pointer errors could be the cause.

"rhoads@cs.rutgers.edu" <rhoads@cs.rutgers.edu> writes:

> The -O3 optimizations are supposed to always produce the same
> results.

No, that's not true.  Optimization should preserve the semantics.
But the semantics often allow more than one result.

If you do something that is "undefined behavior" in C,
the semantics allow more than one result.  In fact, an
infinite number of results.  So turning on optimizations
can easily change which one of those results actually
happens at run time.

>...  Running through the debugger is not supposed to change the
> results either.

Gcc and gdb go to a lot of trouble to make sure the debugger
doesn't perturb the results.  But it's impossible to do that
100%.  For example, stopping at a breakpoint changes the timing
of things, which can cause a multi-threaded program to behave
differently.  Is your program multi-threaded by any chance?
Or handling interrupts/signals?

>...  Has anybody else encountered this behavior?

It's fairly common that turning on optimizations changes results.
Solution: Use a language with fewer cases of "undefined behavior".

It's uncommon for debugging to change results.
But I've seen it happen.
Solution: print-out statements.  (Those can change results, too,
if you're doing undefined behavior.  But you might get lucky.)

- Bob