Sign in to follow this  
AshleysBrain

Release-only bugs?

Recommended Posts

I've been making a simple A* implementation and it works nicely in Debug build. However, when I compile and run it in Release mode, it goes all messed up, and the path goes crazy and takes detours, even when pathfinding between the same two cells as Debug mode. Here's a pic for example: http://www.gullen.pwp.blueyonder.co.uk/releasebuildproblem.jpg I'm not asking specifically about what's gone wrong here. I've had Release-only problems several times before, and they are always incredibly difficult to solve because obviously it's impossible to run an effective debug. I was just wondering if anyone had any hints, tips or techniques to find out what the hell has gone wrong in release mode! Such as, what are the differences between a Debug and Release build which would work in Debug but cause problems in Release? I usually end up trying asserts, messageboxes and the like but it's still never easy. Any ideas anyone?

Share this post


Link to post
Share on other sites
It's probably down to uninitialised variables and/or pointers. In the Debug builds, the compiler sets the variables you use to zero but in your release build this doesn't happen, so you could be starting off with a random number when you expected a zero or a null.

Share this post


Link to post
Share on other sites
There was a great article about this issue in the October 2005 issue of GameDeveloper Magazine. The author, Mick West questions the status quo practice of debug and relase, and offers an alternative.

The article may be available for download for free, but I know you can get a digital version of the issue at: http://www.gdmag.com/archive/oct05.htm for $3.95.

It's worth a read.

Share this post


Link to post
Share on other sites
Quote:
Original post by AshleysBrain
I usually end up trying asserts, messageboxes and the like but it's still never easy.

Unless you are using your own assert functionality, most are not compiled into your code under a release build. So look out for stuff like this...

bool ImportantFunction(void){
// whatever...
return true;
}

int main(int,char**){
// in a release build ImportantFunction will not be called
ASSERT( ImportantFunction( ) )
return 0;
}

[edit]

// for clarity, this is taken from ASSERT.h for VC6
#ifdef NDEBUG
#define assert(exp) ((void)0)
#else
// goes onto define _DEBUG assert
#endif

ASSERT is defined the same way

Share this post


Link to post
Share on other sites
>and they are always incredibly difficult to solve because obviously
>it's impossible to run an effective debug.
You have a debug and a release build. Add a third configuration:
debug-release.

Effectively, it's a copy of the release build, but turn on some
debug settings, like line-info.
It usually helps to find crashes. In your case it'll probably help
less since it's behaving differently, instead of crashing. Maybe
check if your compiler has other settings to give you that little
extra info in a release-build.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It's useful to have a release build that has optimizations turned off, with debug info and asserts turned on. You won't catch everything this way, but it's better than nothing!

In fact, at the company I work for, 99% of the time we program using the release with asserts and debug build, rather than the debug version. (although we have it set up, so that debug info can be turned on and off for certain sections of the code, so that things still run reasonably fast)

Other than that, you're stuck with the usual methods of debug output/logging, or writing functions that test functionality, and putting them in various parts of the code, in order to narrow down which part of the code is going wrong.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
I haven't had to track down a release-only crash in ages. Oh wait, thats because I'm using a non retarded language instead of C++. </flamebait>

<don't-take-this-the-wrong-way-i'm-only-kidding>
So in light of the fact that I use C++ regularly and excluding the extremely low level code I've been writing these last few days I haven't had a release-only crash in ages either (or in fact a crash at all since I rarely use a debugger) where does that put the retardedness? With C++ or with you?
</don't-take-this-the-wrong-way-i'm-only-kidding>

Σnigma

Share this post


Link to post
Share on other sites
You can use #pragma optimize("",off) and #pragma optimize("",on) to turn optimizations off and back on for specific pieces of code.

Also, there's no real hurt to learning how to debug the assembly and watch the values that are going through your registers. If you pay attention to how the compiler is using registers you can provide a type in the watch window like (AStarNode *)eax and it'll understand what you mean.

I've found it's also incredibly useful to use the Memory window (Ctl-Alt-m 1). It lets you view a big chunk of memory as whatever type you want (chars, shorts, floats, longs, etc), and set the number of columns.

Say you have this big array of AStarNode's which each are 16-bytes with 2 pointers and 2 32-bit values. You can set your Memory type to represent 'unsigned / 4-byte int / hexadecimal' and the number of columns to be 4, and you'll see your whole big array at once all nicely lined up. That way, it will be easy to tell at a glance if there's any funny business or uninitialized values sneaking in. It doesn't hurt to watch the memory evolve in debug, and do the same thing in release to see if anything looks fishy.

Of course, it's a little crazy at first :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Enigma
Quote:
Original post by OrangyTang
I haven't had to track down a release-only crash in ages. Oh wait, thats because I'm using a non retarded language instead of C++. </flamebait>

<don't-take-this-the-wrong-way-i'm-only-kidding>
So in light of the fact that I use C++ regularly and excluding the extremely low level code I've been writing these last few days I haven't had a release-only crash in ages either (or in fact a crash at all since I rarely use a debugger) where does that put the retardedness? With C++ or with you?
</don't-take-this-the-wrong-way-i'm-only-kidding>

Σnigma


Dictionary.com
(Definition of 'retarded')

1 - To cause to move or proceed slowly; delay or impede.

Share this post


Link to post
Share on other sites
The thread topic is all too familiar, I've run across this many times too. Yep, problems can be hard to reproduce... however, there is a way to disable the zeroing-out of all values when using Debug mode. That way you can step through the program; It's as if running in Release mode, only Matrix-style (go Neo!).

And I forsee this topic being 10 pages long, since someone insulted C++ (the best language of all time). </more_flamebait>

Share this post


Link to post
Share on other sites
Quote:
Original post by discman1028
And I forsee this topic being 10 pages long, since someone insulted C++ (the best language of all time). </more_flamebait>


Bait accepted. You're clearly an idiot. My revolutionary new language will make C++ look like it was designed by someone less intelligent than a common garden slug high on the best Mendocino weed. GOBOL - Gamers' COBOL - is going to revolutionize game programming. You'll be able to make games with half the typing and a quarter of the thinking that goes into current games. As a bonus (a bonus, people!) it will print out pretty reports.

Share this post


Link to post
Share on other sites

>I haven't had to track down a release-only crash in ages. Oh wait, thats
>because I'm using a non retarded language instead of C++. </flamebait>
Very nice for you,

However I fail to see how your comment helps the original poster.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Kitt3n
Very nice for you,

However I fail to see how your comment helps the original poster.
Then the problem is in you, because his rating is clearly higher than yours. So he must be a helpful poster.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this