Jump to content
  • Advertisement
Sign in to follow this  

Release-only bugs?

This topic is 4447 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
I'm using MSVC++ 6. I thought the debugger always set uninitialised variables to 0xcccccccc, that's what undefined pointers always appear as anyway. Or is it 0 for other data types?

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
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>

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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!