Release-only bugs?
Author
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?
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.
Author
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?
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.
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.
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#endifASSERT is defined the same way
>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.
>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.
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>
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.
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.
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
