Debug vs. Release Mode

by Dan Lloyd

Short Version

Students who use MSVC to do their homework should be sure to test their programs in Release mode (see below for instructions) before turning it in. By default, MSVC builds in Debug mode, which can hide certain kinds of errors from you. When you turn your homework in, it is compiled in Release mode, and so your TA may see bugs that you don't if you test only in Debug mode.

How to Switch Modes

To switch modes, pull down the Build menu and then the Set Active Configuration menu.  You will see a dialog box with two choices, Debug and Release.  Click once on Release and hit the okay button. You now need to rebuild, and then you can run. (To switch back, follow the same procedure, with obvious modifications.)  Most times, if your program was working, it will still be working in Release mode.  If not, though, you should figure out why it has stopped working, with uninitialized variables being at the top of the list of things you suspect.

The Debugger will not work in Release mode, so debugging is much more difficult.   DO NOT simply set your project to Release mode when you begin a homework, on the theory that this will help you get rid of all the bugs more quickly.  The result of doing that will be just the opposite.

Full Explanation

This is just a note about a feature of MSVC that you should be aware of. It may affect your projects so please read on.

MSVC allows you to choose between two modes when you compile: Release mode and Debug mode. The default should be set to Debug mode, and thus, this allows you to debug your program using the debugger. When you build your project in Debug mode, the compiler generates an executable that includes information about your program. For example, it includes all of the names you have used for your variables and how they are associated in your program so that the debugger can know how to refer to a specific value in the program in a way that you will recognize.

If you set MSVC to build in Release mode, then it will generate an executable that is optimized and does not contain this added information.

In the executable generated when building in Debug mode, all of the variables (really the memory locations associated with your variables) are initialized in special ways to help track certain kinds of bugs. For example, if you declare an int, but do not assign it a value, its value will always be:


-858993460

which in base 2 (two's compliment) is:

110011001100110011001100

which is an easy pattern to detect if you are probing the contents of memory using the debugger.

In the executable generated when building in Release mode, there is no special initialization, and if you declare an int, but do not assign it a value, its value is not guaranteed to be anything in particular. In the simple example that I just compiled it was:


4203171

The source code was:

	#include <iostream.h>

	int main(void)
	{
		int i, a[10];  // forgot to initialize i = 9;

		cerr << i << endl;

		while(i >= 0)
		{
			a[i] = 0;
			i = i - 1;
		}
	}

This while loop is meant to initialize the array a to contain 0's. But notice that if we run this in debug mode where the value of i = -858993460, the while statement is skipped and this bug will show up, if at all, later in the execution. Sometimes, this kind of bug will not show up, especially if you are not careful to test your program.

If we run this program in Release mode where the value of i = 4203171, the while condition is true, and it attempts to store a value to a[4203171] which is about 4 Mbytes away from the end of the array. This will cause a segmentation fault since we are trying to modify a memory location that is not in the same segment as this program's data space. This is caught by the operating system and reported in a dialog box. The dialog box will announce that: 


This program has performed an illegal operation and will be shut
down.

If the problem persists, contact the program vendor.

You have probably seen this kind of error (attempting to access a memory location outside of the program's segment) occur with other Windows applications before, but just not realized what was behind it. 

For this class, the important point concerning this issue is that you should always test your project in Release mode before you submit it since that is the mode that we will be testing your project in. After working hard to get your project working, the last thing you want is for us to begin testing your project only to find it crashes every time because you failed to find a bug that only shows up in Release mode.