Debug Mode vs Release Mode C++,
Members - Reputation: 100
Posted 09 February 2010 - 12:46 PM
Moderators - Reputation: 12211
Posted 09 February 2010 - 01:17 PM
Members - Reputation: 3047
Posted 10 February 2010 - 05:28 AM
all that the windows debug information when it crashes says
Just like a crash in debug, a crash in release should still let you bring up the debugger and see exactly1 what line the crash occured on.
As stated above, you are doing "foo->bar" where foo is NULL. Uninitialized variable, or array bounds overstepping is likely the cause.
1 Ok. maybe not exact in release mode. But it should be really close. Optimizations keep the debugger from being able to match everything up perfectly.
Members - Reputation: 143
Posted 10 February 2010 - 10:48 AM
As others have said, Debug apps will generally be more forgiving, since they're intended to be used while you're still working on your program, whereas release is the final, faster, smaller build. Usually Release builds aren't built with debug info(or alot less) to make them more efficient.
For your problem, it sounds like you're going to have to do some good ol' fashion testing and debugging. Find out where you are crashing or what steps to take to make it crash on release, then reproduce in the debug build and find the problem.
If it's not crashing in a debug build, you might trying changing your compile settings and see if you can't get a more Release-type build with some debug info to help you narrow it down.
Members - Reputation: 215
Posted 10 February 2010 - 07:15 PM
If the crash is in assembly code, try walking your way up the callstack, as it's quite likely you passed a null pointer to some api function that doesn't include any symbols.
Crossbones+ - Reputation: 8647
Posted 10 February 2010 - 07:29 PM
Original post by NinjaMonkeyPirate
Not in Visual Studio, at least not with the default options. It usually just breaks into assembly code somewhere.
In my experience, while the immediate crash location in Release builds is often in some location only known as assembly, it pays to take a look at the call stack and jump to the nearest non-assembly location in your own code. Even if the first couple of call stack level are deep down in some Windows DLLs and there is a "may be inaccurate" warning I often enough get a very reasonable idea of where something is going wrong.