Differences that may occur between Debug and Release builds?

Question

I was asked today in an interview to list four differences that may occur between debug and release builds. I suppose they meant differences in behavior and not differences such as debug information and whatnot. I was only able to name two:

Debug builds are generally much slower due to some functions not being inlined.
Due to the difference in speed, in multi-threaded programs that have race conditions, these race conditions may become apparent in only one of the two builds.

What other differences could I have named?

In fact perf differences are usually due to lack of optimisation in debug builds — David Heffernan, May 21 '12 at 15:31
…and additional checks are usually enabled in debug builds. — , May 21 '12 at 15:31
Debug build often links against a different version of the runtime. — David Heffernan, May 21 '12 at 15:32
Some debug builds assign null values to uninitalized pointers. http://stackoverflow.com/questions/186237/program-only-crashes-as-release-build-how-to-debug#187966 — DumbCoder, May 21 '12 at 15:34

score 7 · Answer 1 · answered May 21 '12 at 15:34

Here's a summary of a few differences: http://msdn.microsoft.com/en-us/library/aa236698%28v=vs.60%29.aspx. It includes:

heap layout (the use of a debugging memory allocator)
macros (including assert statements, as well as anything included in "#ifndef NDEBUG", which can be substantial differences in some cases -- e.g., I know that some boost libraries add extra fields to structs when compiled in debug mode, which can be used to perform sanity checks)
optimizations (mostly disabled in debug builds)
initialization & bad pointers: uninitialized variables have undefined state until you assign to them; but in debug builds, they'll often be initialized to some known state (eg all zero or all #CCCCCCC etc).

score 3 · Answer 2 · edited May 23 '17 at 12:33

Besides your two answers, here's another four:

_DEBUG vs NDEBUG
The linker uses different libraries during debug and release
The debug build also produces the symbols used for debugging
Code can end up optimized away, so, in certain situations, you may get fewer calls to some constructors during release, which can cause some nasty bugs. here's an example:

Object x(3);
Object y;
y = x;

versus:

Object x(3);
Object y = x;

score 1 · Answer 3 · answered May 21 '12 at 15:35

Another point is that many libraries have additional checks enabled with debugging. This may ironically mean that code works in debug build, but no in release build:

Imagine an allocation function that zeros out memory in debug build but not in release build due to performance reasons. If the value of this variable is subsequently read without being initialised, the debug build sees a well-defined (zero) value while the release build can see any value.

Conversely, debug build checks can of course catch undefined behaviour e.g. by checking that an access to [] falls within the defined range.

Oh, right. How could I have forgotten about overflow checks? Ahh, damn it! :( — Paul Manta, May 21 '12 at 18:03

Differences that may occur between Debug and Release builds?

3 Answers3

Linked