Reputation: 19325
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...
Any advice?
Upvotes: 3
Views: 1074
Reputation: 19800
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
Upvotes: 0
Reputation: 248269
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.
Upvotes: 8
Reputation: 3281
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.
Upvotes: 16
Reputation: 41519
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.
Upvotes: 3
Reputation: 109180
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...).
Upvotes: 1
Reputation: 132504
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:
assert()
s which are stripped in release mode.volatile
bug) are only hidden in debug mode: they still exist, they are just harder to trigger.Upvotes: 1
Reputation: 61893
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.
Upvotes: 3