Sign in to follow this  
RogerThat123

Debug Mode vs Release Mode C++

Recommended Posts

RogerThat123    100
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..

Share this post


Link to post
Share on other sites
Promit    13246
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.

Share this post


Link to post
Share on other sites
RogerThat123    100
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

Share this post


Link to post
Share on other sites
Vortez    2714
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.

Share this post


Link to post
Share on other sites
KulSeran    3267
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Drakonite    215
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.

Share this post


Link to post
Share on other sites
BitMaster    8651
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.

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