Differences between debug and release versions and debugging problems

I. Memory Allocation Problems

1. The variable is not initialized. The followingProgramIt 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. Assume that you have added the requiredCode
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/a program named debugviewis 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, it is said that it is better to use http://www.gimpel.com/but to convert $.

References:

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

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