Unpredictable behaviour

[rdspicer]

Hi

I have a probelm with a simulation I am running and I was hoping
someone out there may be able to shed some light on the subject.

Before I start, this is what I am using:
MVSC++6.0 (SP6 installed), using 3Ghz Intel machine, Windows Xp, 1.5
Gb SDRAM

This could be a little difficult to explain so please bear with me.

My project is a video encoder that is very big in size and written in C
++.
When I run the sim in Release mode and only when I get to frame 90 do
things start going wrong. However when I run in debug mode, the
projects executes correctly and generates the correct results. Going
back to release mode, I inserted some debugging code (logging
variables to file etc to see if they were in an undefined state etc)
and then the project generated the correct results. So in other words,
only when I was logging specific variables to file in release mode
would the project execute correctly.

Immediately I would think this would be to an uninitialised variable
problem however why is the problem only apparent after 89 frames worth
of encoding? It seems like I have to force the use of these variables
for them to be used correctly. Am I losing the plot?

I have tried to use BoundsChecker to trap any memory leaks and pointer
problems, however because the project is so big and under normal
conditions is so slow to execute, BoundsChecker seems to grid to a
halt and never gets anywhere!

Any suggestions on what else to consider or how to trap this little
nasty?

Many thanks
Ryan

 

[Ron Natalie]

That's the insidious feature of undefined behavior. It may indeed
work normally for a while.

There are several things that are different in debug mode and can
be peturbed by inserting inline debugging statements.

Check all your dynamic memory allocation. Any chance you are
writing off the end of an allocation. Eschew managing your own
memory in favor of classes that are already debugged like the
standard containers and strings.

Check array subscripting.

Initialize EVERYTHING. Better to have a deterministic ZERO
than an indeterministic state.

 

[Jim Langston]

That's the insidious feature of undefined behavior. It may indeed
work normally for a while.

There are several things that are different in debug mode and can
be peturbed by inserting inline debugging statements.

Check all your dynamic memory allocation. Any chance you are
writing off the end of an allocation. Eschew managing your own
memory in favor of classes that are already debugged like the
standard containers and strings.

Check array subscripting.

Initialize EVERYTHING. Better to have a deterministic ZERO
than an indeterministic state.

Right. Variables are laid out differently in release mode and debug mode.
The two normal causes of something working in one mode and not the other are
unititialized variables and array over/under flows. Try turning on array
bounds checking in debug mode and see if anything comes up. Tripple check
all your writings and readings from pointers and arrays. That is probably
where the error is.

 

[Ron Natalie]

Right. Variables are laid out differently in release mode and debug mode.
The two normal causes of something working in one mode and not the other are
unititialized variables and array over/under flows.

Yeah, I didn't want to get two involved in Micrsnot specifics but:

In debug mode, supposedly uninitialized memory is initialized with
a distinctive pattern. There is extra "guard" areas allocated
around dynamic allocations which is also filled with a distinctive
pattern. Freed memory is filed with another pattern.

In release mode, nothing is filled that isn't expressly initialized.
New allocations can have anything (and often have zeros in them).
There are no guard bands around the allocations, if you overwrite
your allocation you almost certainly trash the arena.

There are calls in debug mode you can add that will check the
consistancy of the dynamic allocation.

Again best guard against undetermined contents is to *ALWAYS*
initialize things, even if it is an inappropriate default
value. At least then your errant program misbehaves consistantly.

 

[Dave Rahardja]

Hi

I have a probelm with a simulation I am running and I was hoping
someone out there may be able to shed some light on the subject.

Before I start, this is what I am using:
MVSC++6.0 (SP6 installed), using 3Ghz Intel machine, Windows Xp, 1.5
Gb SDRAM

This could be a little difficult to explain so please bear with me.

My project is a video encoder that is very big in size and written in C
++.
When I run the sim in Release mode and only when I get to frame 90 do
things start going wrong. However when I run in debug mode, the
projects executes correctly and generates the correct results. Going
back to release mode, I inserted some debugging code (logging
variables to file etc to see if they were in an undefined state etc)
and then the project generated the correct results. So in other words,
only when I was logging specific variables to file in release mode
would the project execute correctly.

Don't forget this could also be an artifact of optimization. Sometimes
adding logging to expose a variable's value prevents that variable from
being optimized away.

Are you doing any multithreading?

-dr

 

[Ron Natalie]

Don't forget this could also be an artifact of optimization. Sometimes
adding logging to expose a variable's value prevents that variable from
being optimized away.

Correct, but in my experience, such issues are few and far between
compared to the other.

Are you doing any multithreading?

This is another point. In debug mode windows inhibits any real
concurrency of processing that might occur if you have real
multiple threads (hyperthreads, multiple processors, dual core...)