views:

557

answers:

7

So I have just followed the advice in enabling debug symbols for Release mode and after enabling debug symbols, disabling optimization and finding that break-points do work if symbols are complied with a release mode, I find myself wondering...

  1. Isn't the purpose of Debug mode to help you to find bugs?
  2. Why bother with Debug mode if it let bugs slip past you?

Any advice?

+3  A: 

Optimisations will be turned off, which makes debugging easier (otherwise code can be reordered in strange ways). Also conditional code such as assert() etc. can be included.

Ruben Bartelink
+1  A: 

Bugs due to optimisers aren't unheard of; but normally they hint at a deeper problem, for instance, not using volatile when you need to will cause optimiser bugs (optimising away comparisons and using cached results instead).

At the end of the day, including debug symbols in early releases can help you trace down bugs after deployment.

Now, to answer your questions directly:

  1. Debug mode has other things, like assert()s which are stripped in release mode.
  2. Even if you do all your testing in release mode, bugs will still slip by. Infact, some bugs (like the above volatile bug) are only hidden in debug mode: they still exist, they are just harder to trigger.
Matthew Scharley
+1  A: 

Including full symbols with your application includes significant information about the build machine (paths etc. are embedded).

The advice is to include "PDB Only" symbols with release builds (don't include file, line and local variable symbols) with optimisation on. And debug build has no optimisation and full symbols.

And (as noted in other answer) common sub-expression elimination and instructin reordering can make debugging interesting (move next goes to lines n, n+2, n+1...).

Richard
+3  A: 

Apart from your application being very debuggeable in release mode, the MSVC runtime libraries aren't so nice, neither are some other libraries.

The debug heap, for instance, adds no-man's land markers around allocated memory to trap buffer overruns. The standard library used by MSVC asserts for iterator validity. And much more.

xtofl
A: 

optimization is a nightmare for debugging. Once i had an application with this for loop

for (int i = 0; i < 10; i++)
{
  //use i with something
}

i was always 0 in debugging. but outputting it to a console showed that it did increase

PoweRoy
If all you were ever doing is printing it, it's entirely possible that memory was allocated for your variable then was never used, prefering to cache `i` in a register. Tricksy.
Matthew Scharley
The word you're looking for is "optimization", not "optimalisation". :)
jalf
+14  A: 

In truth there is no such thing as a release mode or a debug mode. there are just different configurations with different options enabled. Release 'mode' and Debug 'mode' are just common configurations.

What you've done is to modify the release configuration to enable some options which are usually enabled in the debug configuration.

Enabling these options makes the binaries larger and slower according to which ones you enable.

The more of these options you enable, the easier it is to find bugs. I think your question should really be "Why bother with release mode?" The answer to that is that it's smaller and faster.

Paul Mitchell
+7  A: 

Debug mode doesn't "let bugs slip past you". It inserts checks to catch a large number of bugs, but the presence of these checks may also hide certain other bugs. All the error-checking code catches a lot of errors, but it also acts as padding, and may hide subtle bounds errors.

So that in itself should be plenty of reason to run both. MSVC performs a lot of additional error checking in Debug mode.

In addition, many debug tools, such as assert rely on NDEBUG not being defined, which is the case in debug builds, but not, by default, in release builds.

jalf