Problem only in release version!

[babak]

Hi everybody
I'm working with a project in embedded Visual Studio 4 and I have a
general problem which I hope that somebody can help me with. My problem
is the following:
My project works fine in debug version but behaves strangely and
sometimes crashes when I run it in release version. I suspect that it
is some sort of memory problem but it is not that easy to find out what
the problem exactly is (the project is rather big with maybe 30000
lines of code).
It should be the same code that runs in the both versions, right? Or is
there some part of the code in a project that might differ in debug and
release version?

Thanks for all your help.
Regards.
/Babak

 

[Jochen Kalmbach [MVP]]

Hi babak!

My project works fine in debug version but behaves strangely and
sometimes crashes when I run it in release version.

See: Surviving the Release Version
http://www.flounder.com/debug_release.htm

Mostly it has to do with uninitialized data (in debug this data will get
soe "default" value; but in release it will get some random numbers).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Peter Oliphant]

Just to affirm Jochen's point, the Debug version initializes most variables
to zero. The Release version will not initialize anything 'naturally'
(meaning without you writing code to do so), and hence many of the variable
are often given a 'random' value upon loading ('random' in that they keep
the contents of the memory addresses they happen to get assigned to).

Thus, your new errors are likely the result of some variable that works fine
if initialized to zero, but don't work if not initialized to zero (or not in
some range, non-negative, etc.). Since an application doesn't always get
loaded at the same place and memory, and because even the same place in
memory can have different values depending on when you load your program
(that's why it's RAM not ROM...hehe), you can get random bugs and un-stable
executions of the Release version (i.e., it might do different things on
different runs depending on the 'random' nature of your variables) even if
it is totally stable in Debug mode.

Hope that helps!!! : )

 

[babak]

Jochen and Peter,
Thanks for your replies. Now the problem for me is to find out where in
my code variables could be uninitialized... (as I said before, it is a
huge project I'm running).

Regards.
/Babak

 

[Jochen Kalmbach [MVP]]

Hi babak!

Thanks for your replies. Now the problem for me is to find out where in
my code variables could be uninitialized... (as I said before, it is a
huge project I'm running).

AFAIK VC7.1/8 informs you about uninitialized variables.

See: C4700
http://msdn.microsoft.com/library/en-us/vccore/html/c4700.asp

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[David Lowndes]

the Debug version initializes most variables to zero.

In another bid to dispel this myth - a debug build doesn't do this.

In newer versions of VC++, the compiler has run-time diagnostic
options that will initialise automatic (stack) variables to a special
value in order to detect use of an uninitialised variable. If this
option isn't used, automatic variables are pseudo-random values that
might have a higher probability of being zero in a debug build.
There's no magic that initialises automatic variables to zero in debug
builds.

Dave

 

[Olaf Baeyens]

Thanks for your replies. Now the problem for me is to find out where in

my code variables could be uninitialized... (as I said before, it is a
huge project I'm running).

30000 lines is not really a big project ;-)
But maybe for embedded it is.

The problem is that it could be anything causing it.
So some questions:
* Did you create the code yourself?
* Did it ever work?
* When did you notice when it didn't work anymore?
* What did yo chance before you discovered this problem?
* Do you initialize every variable yourself?
* Are you using multi-threading?

The difference between release and debugging could be that your code is
mapped differently.
For example: You might have and unitialized pointer that by luck points to a
memory that does not generate an access violation in the debug version but
does in the release.

Another thing might be timing, release is faster and you might end up into a
racing condition.
Or if you use multi threading that somehow you gets into a deadlock.

One thing you could try is to run the debugging version on a different
computer. See if the problem occurs, it might be there, but so far you did
not notice it.

I hope this helps to point you in th right direction.

 

[Tom Serface]

If it is crashing I'd check overflowing of variable space on the stack
(local variables). For example, if you set up a char buffer to hold 10
chars and you add 11 to it. This kind of thing is very easy to do. The
Debug version may still have the problem, but the stack space is better
protected and the memory is not arranged the same so at run time even if the
problem is really still there it may not crash your program.

As others have suggested uninitialized pointers, etc. are flagged at compile
time so you'd see those warnings at least. However, going beyond allocated
memory or a buffer on the stack is not always caught.

Of course, if this is all managed code, that's not supposed to happen, but
VC allows native and mixed which opens it up again.

Tom

 

[Doug Harrison [MVP]]

Just to affirm Jochen's point, the Debug version initializes most variables
to zero. The Release version will not initialize anything 'naturally'
(meaning without you writing code to do so), and hence many of the variable
are often given a 'random' value upon loading ('random' in that they keep
the contents of the memory addresses they happen to get assigned to).

The debug version doesn't initialize anything to zero that isn't
zero-initialized in the release version. The /RTCs documentation explains
why you're more likely to observe zero as the value of uninitialized
stack-based variables in debug builds that don't use /RTCs.

/RTC (Run-Time Error Checks)
http://msdn.microsoft.com/library/d...y/en-us/vccore/html/vcrefrtcruntimechecks.asp

In addition, the debug heap manager sets memory to certain non-zero values
to help diagnose heap errors.

Thus, your new errors are likely the result of some variable that works fine
if initialized to zero, but don't work if not initialized to zero (or not in
some range, non-negative, etc.). Since an application doesn't always get
loaded at the same place and memory, and because even the same place in
memory can have different values depending on when you load your program
(that's why it's RAM not ROM...hehe), you can get random bugs and un-stable
executions of the Release version (i.e., it might do different things on
different runs depending on the 'random' nature of your variables) even if
it is totally stable in Debug mode.

The OS (NT-based Windows anyway) only ever hands out memory pages
initialized to zero. In fact, there's an OS thread whose purpose in life is
to populate a zeroed page list:

Inside Memory Management, Part 2
http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=3774
<q>
Pages on the standby page list move to the zeroed page list after a special
thread, called the zero-page thread, clears their content. The zero-page
thread executes in the background at priority 0. It runs only if no other
thread can run, and its job is to move pages from the free page list to the
zeroed page list as it clears their content.
....
The necessity of zeroing a page before assigning it to the working set of a
different process is a C2 security requirement.
</q>

 

[Peter Oliphant]

So I was right for the wrong reason then.... : )

By the way, another less likely 'source' of the problem is if any of the
application has required code in an 'assert'. Any code in an 'assert' is is
not executed in Release mode (I believe, but I also thought Debug
initialized variables to zero, so what do I know...hehe) .

Most people don't put anything but comparison checks in asserts, and not
functioning code, but you never know... : )

 

[Doug Harrison [MVP]]

So I was right for the wrong reason then.... : )

By the way, another less likely 'source' of the problem is if any of the
application has required code in an 'assert'. Any code in an 'assert' is is
not executed in Release mode (I believe, but I also thought Debug
initialized variables to zero, so what do I know...hehe) .

It's true; asserts go away entirely in Release mode. (More generally, the
standard assert macro expands to nothing if NDEBUG is #defined, while MFC's
ASSERT goes away if _DEBUG isn't #defined.)

Most people don't put anything but comparison checks in asserts, and not
functioning code, but you never know... : )

It definitely happens. Besides code that does something overtly, you should
also avoid asserting on code that can have more or less subtle side
effects, such as throwing exceptions. Ideally, your asserts or _DEBUG code
cannot change any application state.