Differences between debug and release versions

This article mainly includes the following content:
1. essential differences between debug and release compilation methods
2. under which circumstances will the release version go wrong?
2. How to "debug" release programs

I. essential differences between debug and release compilation methods
Debug is usually called a debug version. It contains debugging information without any optimization, so that programmers can debug the program easily.
. Release is called a release version. It is often optimized to make the program run at the code size and speed.
Is optimal, so that users can use it well.
The real secret of debug and release lies in a set of compilation options. The options for the two are listed below.
(Of course there are others, such as/FD/Fo, but the difference is not important. Generally, they do not cause rele.
ASE version error, not discussed here)

Debug version:
/MDD/MLD or/MTD use the debug Runtime Library (the runtime function library of the debug version)
/OD turn off the optimization Switch
/D "_ debug" is equivalent to # DEFINE _ Debug. Enable the compile and debug code switch (mainly
Assert function)
/Zi creates the edit and continue (Edit to continue) database, so that the database has been debugged
If the source code is modified, you do not need to re-compile it.
/GZ helps capture Memory Errors
/GM enables the minimize reconnection switch to reduce the link time

Release Version:
/MD/ml or/MT use the runtime function library of the released version
/O1 or/O2 optimization switch to minimize or minimize the program
/D "ndebug" Disable the Conditional compilation and debugging code switch (that is, do not compile the assert function)
/GF combines repeated strings and puts string constants in read-only memory to prevent
Modified
In fact, there is no essential limit between debug and release. They are just a set of compilation options.
Only follow the predefined options. In fact, we can even modify these options to get optimized calls.
Trial version or release version with tracking statement.

Ii. under which circumstances will the release version go wrong?

With the above introduction, let's compare these options one by one to see how release errors are generated.

1. Runtime Library:

2. Optimization: There are mainly the following types of errors:

(1) frame pointer (frame pointer) omitted (FPO for short): All call information during function call
(Return address, parameters) and automatic variables are all placed in the stack. If the declaration and implementation of a function are different (parameter, return
Back value, call method), it will produce an error ---- but in debug mode, stack access through the EBP register
If there is no array out-of-bounds error (or not many), the function usually can
Normal execution; In the release mode, the optimization will omit the base address pointer of the EBP stack, so that a global pointer is used to access the stack.
The returned address is incorrect because the program crashes. C ++'s strong type feature can check for most of these errors, but for example
If forced type conversion is used, it will not work. You can add the/Oy-compilation option to the release version.
The drop frame pointer is omitted to determine whether such an error occurs.
(2) Volatile variable: Volatile tells the compiler that the variable may be modified in an unknown way outside of the program.
(Such as systems, other processes, and threads ).

(3) Variable Optimization: The optimization program optimizes the variables based on the usage of the variables. For example, one of the functions is not
The variable used in the debug version may mask an array out of bounds. In the release version, this variable
It is likely to be optimized. In this case, the array out of bounds will destroy useful data in the stack. Of course, the actual situation is more complicated than this.
Yes. Related errors include:

3. _ debug and ndebug: When _ debug is defined, the assert () function will be compiled, while ndebug does not
Compiled. In addition, there are a series of assertion Macros in VC ++. This includes:

Ansi c asserted void assert (INT expression );
C Runtime lib assert (booleanexpression );
_ Asserte (booleanexpression );
MFC assert (booleanexpression );
Verify (booleanexpression );
Assert_valid (pobject );
Assert_kindof (classname, pobject );
ATL assertion atlassert (booleanexpression );
In addition, the compilation of the trace () macro is also controlled by _ debug.

4./GZ option: This option will do the following:

(1) initialize memory and variables.
(2) When a function is called through the function pointer, the matching of the function call is verified by checking the stack pointer. (Prevent original
Shape mismatch)
(3) Check the stack pointer before the function returns, and confirm that it has not been modified.

3. How to "debug" release programs

1. As mentioned above, debug and release are only the differences between a set of compilation options. In fact, there is nothing
The definition can distinguish the two. We can modify the compilation option of release to narrow down the error range. As mentioned above, you can
Change the release options to the corresponding debug options one by one, for example,/MD to/MDD and/O1 to/OD.
Or change the running time to program size optimization. Note that only one option is changed at a time to see which option is incorrect
Errors related to the options are found. These options are available in project \ Settings...
Select directly from the list. Do not manually modify it. Since the above analysis is quite comprehensive, this method is the most
Valid.
2. You can debug your release version just like debug. In Project/s
In ettings..., select Settings for "Win32 release", C/C ++, and category.
General, debug info Select Program database. At the end of the link tag project options
Add "/OPT: ref" (do not enter the quotation marks ).

 

I. Memory Allocation Problems

1. The variable is not initialized. The following program runs well in debug.

Thing * search (thing * something)
Bool found;
For (INT I = 0; I <whatever. getsize (); I ++)
{
If (whatever [I]-> Field = something-> field)
{/* Found it */
Found = true;
Break;
}/* Found it */
}
If (found)
Return whatever [I];
Else
Return NULL;
But not in release, because in debug, found = false is automatically initialized for the variable, but not in release. Initialize variables, classes, or structures as much as possible.

2. Data Overflow

For example, char buffer [10];
Int counter;

Lstrcpy (buffer, "abcdefghik ");

In the debug version, the buffer's null overwrites the counter's high position, but unless counter> 16 m, there is no problem. However, in the release version, counter may be placed in the register, so that null overwrites the space in the buffer, which may be the return address of the function, leading to access error.

3. The memory allocation methods for debug and release versions are different. If you apply for 6 * sizeof (DWORD) = 24 bytes for ele in debug, you are actually allocated 32 bytes (32bytes for Debug ), in the release version, 24 bytes are allocated to you (8 bytes for the release version). Therefore, if you write ele [6] In the debug version, there may be no problems, in the release version, access violate exists.

Ii. Assert and verify

1. Assert will not be compiled in the release version.

The assert macro is defined in this way.

# Ifdef _ debug
# Define assert (x) if (x) = 0) report_assert_failure ()
# Else
# Define assert (X)
# Endif
Actually complicated, but irrelevant. If you add the Code required by the program to these statements
For example

Assert (pnewobj = new cmyclass );

Pnewobj-> myfunction ();

In this case, pnewobj in the release version is not allocated to space.

Therefore, when the next statement is executed, the program reports that the program has performed illegal operations. In this case, you can use verify:

# Ifdef _ debug
# Define verify (x) if (x) = 0) report_assert_failure ()
# Else
# Define verify (x) (X)
# Endif
In this way, the code can be executed in the release version.

Iii. Parameter issues:

The custom message processing function must be defined as follows:

Afx_msg lresult onmymessage (wparam, lparam );

The returned value must be hresult type. Otherwise, the debug will pass, and the release will fail.

Iv. Memory Allocation

Ensure uniformity of Data creation and clearing: If a DLL provides a function that can create data, the DLL should also provide a function to destroy the data. Data creation and cleanup should be at the same level.

V. dll disaster

People will mix different versions of DLL to create a non-consistent image called "dynamic Connection Library hell" (DLL hell), even Microsoft said so (http://msdn.microsoft.com/library/techart/dlldanger1.htm ).

If your program uses your own DLL, note the following:

1. You cannot mix debug and release DLL versions. Both debug and release versions are release.

The solution is to put the debug and release programs under the debug and release directories of the main program respectively.

2. Never think that static connection to the database will solve the problem, which will only make the situation worse.

Debugging in the vi. Release Board:

1. Change assert () to verify (). Find the code defined in "# ifdef _ debug". If you need the code in the release version, move it out of the definition. Find the code in trace (...) because the code is not compiled in release. Check whether the Code required in the release is not cheap.

2. The differences brought about by variable initialization exist in different systems or between debug/release versions. Therefore, initialize the variables.

3. Is there a warning during compilation? Set the warning level to 3 or 4, and ensure that no warning appears during compilation.

VII. Change the optimization option under the "C ++/C" project in project settings to disbale (Debug ). Compiler Optimization may cause many unexpected errors, please refer to http://www.pgh.net /~ Newcomer/debug_release.htm

1. You can also debug the software of the release version. Make the following changes:

Set "category" to "general" under "Project Settings" C ++/C "and" debug info "to" program database ".

Select the "Generate debug info" check box under the "Link" project.

"Rebuild all"

Some restrictions arising from this practice:

The value of the variable in the mfc dll cannot be obtained.

All DLL projects used by the software must be modified.

In addition:

Ms bug: A Ms technical document shows that the "maximize speed" optimization option for DLL in vc5 is not fully supported, therefore, this will cause memory errors and cause program crashes.

2. www.sysinternals.com has a program called debugview, which is used to capture output of outputdebugstring. After running (it is estimated that it is set to system debugger), you can view output of outputdebugstring of all programs. After that, you can run your program and view debugging information without using VC.

3. There is a static code check tool named gimpel lint, which is said to be easy to use. Http://www.gimpel.com is just $.

References:

1) http://www.cygnus-software.com/papers/release_debugging.html

2) http://www.pgh.net /~ Newcomer/debug_release.htm

 

In VC, when the entire project is large, the software often fails to run in the debug State but in the release state. Because developers usually develop software in the debug state, this often happens when we prepare to release the software with confidence after one or two months of hard work. To avoid unnecessary losses, we 'd better perform the following checks:

1. Often test the two software versions.

2. Do not attribute the issue to debug/release unless you have fully tested the two versions.

3. Differences in Preprocessing may also cause such problems.
One possibility of a problem is that different pre-processing tags are defined during compilation of different versions. Try the following changes to your debug software:

In the C/C ++ item in "project setting (ALT-F7)", set the directory (Category) to "general" and change "_ debug" to "ndebug ".
Set the directory to "Preprocessor" and add definition "_ debug to" undefined symbols "input box.
Select rebuild all and recompile.
If a problem occurs in the compiled program, make the following changes to the Code:
Change assert () to verify (). Because the content in assert is not compiled in the release version.
Find the code defined in "# ifdef _ debug". If you need the code in the release version, move it out of the definition.
Find the code in trace (...) because the code is not compiled in release.
Therefore, check whether the Code required in the release is not compiled.

4. The differences brought about by variable initialization exist between different systems or debug/release versions. Therefore, initialize the variables.

5. Is there a warning during compilation? Set the warning level to 3 or 4, and ensure that no warning appears during compilation.

6. Whether the resource file has been changed.

7. You can also debug the software of the release version. Make the following changes:

Set "category" to "general" under "Project Settings" C ++/C "and" debug info "to" program database ".
Select the "Generate debug info" check box under the "Link" project.
"Rebuild all"
Some restrictions arising from this practice:
The value of the variable in the mfc dll cannot be obtained.
All DLL projects used by the software must be modified.

In addition:
Ms bug: A Ms technical document shows that the "maximize speed" optimization option for DLL in vc5 is not fully supported, therefore, this will cause memory errors and cause program crashes.