Debug Mode vs Release Mode C++
Author
Hello all.
I have an application that I made that I compile in debug mode for myself. It is written on visual studio 2008 pro, and when I run it it works perfectly!
This debug version though on other pc's doesnt work (on the odd one it will). Maybe you need visual studio 2008 installed or something. I tried installing the visual studio 2008 runtimes and redistributable package on my other pc's too. This fixed a couple but most did not work.
So I then compiled in release mode.. But the problem is that Release mode crashes randomly! I have no clue why.. It crashes on every computer... But on startup it launches fine on every computer. Its just when you begin to use it it crashes.
But like I said the debug version works perfect for my pc, and on most others it doesn't work at all.
Im stuck..
The debug build uses a different set of runtimes that are only installed on developer machines, and include a lot of extra checks and debugging help. The correct thing to do is to find out why your Release build crashes. Those builds ARE debuggable you know. Figure out where it crashes and work from there.
Author
I did click debug but it didnt show me in my compiler where it was crashing...
all that the windows debug information when it crashes says
Exception Code: c0000005
Exception Offset: 00000000
That offset isnt really helpful
all that the windows debug information when it crashes says
Exception Code: c0000005
Exception Offset: 00000000
That offset isnt really helpful
Yes, it is. You're getting an access violation (0xC0000005) when you access a null pointer.
Yea, you probably forgot to initialize some pointers or variables, wich the debug version do for you i think but not in release. Always initialize everything you create.
Quote:
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.
Not in Visual Studio, at least not with the default options. It usually just breaks into assembly code somewhere.
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.
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.
Check your build settings for release to make sure it'd creating debug symbols. I believe the default project settings in VS2008 should be creating a pdb containing the debug symbols.
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.
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.
Quote: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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
