Understanding the difference between debug mode and release mode

[LarryChen]

As we know, there is four differences between debug mode and release mode, .ie.,

1. heap layout (you may have heap overwrite in release mode - this will cause 90% of all problems),

2. compilation (check conditional compilation statements, assertion functions etc.),

3. pointer support (no padding in release mode which may increase chances of a pointer to point into sky)

4. optimization.

Here I am trying to understand them as much as I can. The following is the parts I don't really understand.

As for 1, what is heap overwrite?

As for 3, what is padding for pointer?

As for 4, what is the difference in optimization in terms of release and debug mode?

[Alex F]

There are two places to search for a differences between Debug and Release:
1) Compiler and linker flags. Compare them and read about every flag that has different values.
2) Conditional compilation. When _DEBUG constant is defined, some libraries and headers have different behavior. For example, C++ new operator is redefined as DEBUG_NEW operator, which keeps allocated object together with a file name and line number, where this allocation was done. Most assertions exist only in Debug configuration.

Regarding optimization. Non-optimized code is executed exactly as it is written. When you debug Debug configuration, executable code matches exactly the source code. Trying to debug Release configuration, you can see that many functions don't exist (inlined), many variables don't exist as well (replaced with constants, registers etc.), and generally, executable code does not match the source code.

[Lindley]

Regarding optimization. Non-optimized code is executed exactly as it is written. When you debug Debug configuration, executable code matches exactly the source code. Trying to debug Release configuration, you can see that many functions don't exist (inlined), many variables don't exist as well (replaced with constants, registers etc.), and generally, executable code does not match the source code.

Yes, but on the other hand, it is very easy to turn off optimizations in Release configuration for debugging purposes. Sometimes, debugging in the Release configuration makes sense, so it's important to realize this.

[monarch_dodra]

Not to mention performance. Some programs are so SLOW in debug mode that you'll have to tweak the optimizations settings if you want it to even start.

[LarryChen]

It is very informative. Would you mind telling me how to check compiler and linker flags? Also what is the heap overwrite? What is padding for a pointer? Thanks.

There are two places to search for a differences between Debug and Release:
1) Compiler and linker flags. Compare them and read about every flag that has different values.
2) Conditional compilation. When _DEBUG constant is defined, some libraries and headers have different behavior. For example, C++ new operator is redefined as DEBUG_NEW operator, which keeps allocated object together with a file name and line number, where this allocation was done. Most assertions exist only in Debug configuration.

Regarding optimization. Non-optimized code is executed exactly as it is written. When you debug Debug configuration, executable code matches exactly the source code. Trying to debug Release configuration, you can see that many functions don't exist (inlined), many variables don't exist as well (replaced with constants, registers etc.), and generally, executable code does not match the source code.

[VladimirF]

There are no Debug or Release “modes”.
These are the common names of project’s configurations. And the only REAL difference is the purpose of those configurations: to be released to the public, or to be debugged.
There might be multiple debug and release configuration in a project; they can be as similar or as different as the software designer wants them to be.
The typical differences in different configurations are mentioned above, but any and all project’s properties might be set differently for various configurations.

...what is the heap overwrite? What is padding for a pointer?

Heap overwrite is when you write your data past the allocated memory block. In debug CRT, these blocks might be padded so that few bytes overwrite will not cause any problems.
I’ve never heard about “pointer padding”.

[ninja9578]

In debug mode I have asserts EVERYWHERE. Any time I use a pointer, there is almost always an assert before it checking whether or not it's null. In debug modes I write debugging information out to files. This makes it many many many times slower than the release mode, but gives me all of the information that I need to properly debug.

I also do this quiet a bit:

#ifdef UNITTEST
   #declare PRIVATE_STUFF private:
#else
   #declare PRIVATE_STUFF
#endif

That makes all private members and methods accessible to my unit tests, which makes my test suite more extensive so I'm that much more sure that nothing will go wrong when I release it.

[ninja9578]

If pointer padding is what I think it is then I use it occasionally, mostly for strings. I almost never use it in C++ however, usually with C.

inline char * _malloc(size_t count){
    #ifndef NDEBUG
	   char * res = (char*)malloc(count + 8);
	   assert(res);
	   *((unsigned int*)res) = *((unsigned int*)&res[count]) = 0xDEADBEEF;
	   return res + 4;
    #else
	   return (char*)malloc(count);
    #endif
}

inline void _set(char * p, char value){
    #ifndef NDEBUG
	   assert(*((unsigned int*)p) != 0xDEADBEEF);
	   assert(*((unsigned int*)p - 1) != 0xDEADBEEF);
	   assert(*((unsigned int*)p - 2) != 0xDEADBEEF);
	   assert(*((unsigned int*)p - 3) != 0xDEADBEEF);
    #endif
    *p = value;
}

inline void _free(char * p){
    #ifndef NDEBUG
	   assert(*((unsigned int*)(p - 4)) == 0xDEADBEEF);
	   free(p - 4);
    #else
	   free(p);
    #endif
}

int main(){
    char * str = _malloc(25);
    _set(str, 'a');
    _free(str);
    return 0;
}

I always called it buffer padding though, pointer padding sounds like it has something to do with the pointer itself. It does make debugging quiet a bit easier because gdb has a nice memory viewer, and this makes it easy to see where the allocated blocks begin and end.

Or, do you mean padding to the beginning and or ends of buffers to make them line align with memory? new does this, malloc does not.

[Alex F]

Open project properties, C/C++ and linker settings. For every page, compare settings, switching between Debug and Release configurations. If you see the difference, read more about this compiler/linker flag.
Learning by this way, you can see actual difference between Debug and Release. Debug and Release are just two common sets of compiler and linker flags.