[Switch] differences between debug and release

Differences between debug and release in VC

During the code writing process recently, it is found that debug runs normally, and problems may occur in release, which cannot be solved, but cannot be debugged in release, therefore, you can only gradually locate the problem in printf mode to find that the original array is not initialized, resulting in an exception in subsequent processing. I found some information on the Internet and summarized it as a memo ~
I. Differences between debug and release
Debug is usually called a debug version. It contains debugging information without any optimization, so that programmers can debug programs easily. Release is called a release version. It is often optimized to optimize the code size and running speed, so that users can use it well.
The real difference between debug and release lies in a set of compilation options.
Debug version
Parameter description
/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 for the assert function)
/Zi
Create the edit and continue database, so that you do not need to re-compile the source code if the source code is modified during debugging.
GZ helps capture Memory Errors

Description of release version Parameters
/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 Modification

There is no essential limit between debug and release. They are just a set of compilation options, and the compiler only acts according to the predefined options.

Related Experience: From http://dev.csdn.net/article/17/17068.shtm
1. variables.
As we all know, the operations performed by debug and release when initializing variables are different. debug assigns each byte to 0xcc (note 1 ), the value assignment of release is similar to random (I think it is allocated directly from the memory and has not been initialized ). This makes it clear that if a variable in your program is referenced when it is not initialized, it is likely that an exception occurs: using it as a control variable will lead to inconsistent process orientation; using it as an array subscript will cause the program to crash; it is more likely to cause other errors due to inaccuracy of other variables. Therefore, initializing a default value immediately after declaring a variable is the simplest and most effective method. Otherwise, there is no place to find it when the project is too large. Code errors may be ignored and not noticed in the debug mode. For example, in the debug mode, most arrays do not go out of bounds and are exposed in the release, this is hard to find: (Please pay more attention to it .)
Oh, it's my problem ~~
2. Customize message parameters.
MFC provides us with a good message mechanism and adds custom messages, so I don't need to talk about the benefits. Is there a problem with debug and release? The answer is yes. When declaring the function body of a custom message, you will often see the following statement: afx_msg lresult onmessageown (); In debug mode, there will generally be no problems, however, when you use a message in a multi-thread or process in a release environment, it will lead to errors such as invalid handles. The direct cause of this error is that the message body parameter is not added, that is, it should be written as afx_msg lresult onmessageown (wparam, lparam); (note 2)
3. There is no error in release mode, but an error is reported in debug mode.
In this case, most of them are caused by Incorrect code writing. You can view the source code of MFC and find many assert statements (assertions). This macro is only valid in debug mode, it is clear that the release version does not report errors because it ignores errors rather than no errors. This may pose a major risk because it is easier to debug in debug mode, check your code, and I will not talk about it more.
4. assert, verify, trace ...... debug macro
This situation can be easily explained. For example, enter assert under VC and select F12 to jump to the macro-defined place. Here you can find that assert in debug needs to execute afxassertfailedline, the macro definition in release is "# define assert (f) (void) 0 )". Therefore, do not use program variables such as I ++ write statements to debug macro statements. Verify is an exception, "# define verify (f) (void) (f)", that is, execution, the role is not pursued here, interested in your own research :).

Summary:
Different Problems With Debug and release often occur at the beginning of code writing. 99% is caused by Incorrect code writing, so do not talk about system problems or compiler problems without moving them, the reason for trying to find yourself is the root cause. I used to encounter this situation many times. I started to pay attention to it once and again, and now I have not encountered this problem for a long time in the code I have written. The following are several aspects to avoid. Even if there is no such problem, you should pay attention to it:
1. Pay attention to the initialization of variables, especially pointer variables, array variables (in large cases, another consideration ).
2. Standard Writing of custom messages and other declarations
3. It is best to comment out the code after debugging a macro.
4. Try to use try-catch (...)
5. Try to use the module to make it clear and easy to debug.
Note 1:
The debug version is initialized to 0xcc because 0xcc is an int 3 single-step interrupt command in x86, so that the program will stop when it encounters 0xcc, this is the same as the JMP 0000 statement that is useless in single-chip microcomputer programming. It is attached to: Computer second-level examination _ examination large [Editor: drfcy Error Correction]


[VC] Debug and release: on Sunday, November 3, August 26, 2007 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 refer to the inconsistency image caused by the mix of different versions of DLL called "the hell of dynamic Connection Library" (DLL hell), and even Microsoft itself 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 the 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. http://www.sysinternals.com/there is a program debugview, which is used to capture output of outputdebugstring. After running it (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, it is said that it is better to use http://www.gimpel.com/but to convert $.

[Switch] differences between debug and release