[Debug] Debug the release version Application

Introduction

If you encounter a common error during your development, maybe your release version cannot run normally and the debug version runs correctly, I recommend that you read this article: because not as you think, the release version can ensure that your applicationProgramIt can run like the debug version.

If you have never performed a release test after the development phase is complete or within a period of time during development, but you have found problems during the test, please refer to our debugging rule 1:

Rule 1: conduct regular debugging and release tests on the development software.

The longer the time interval for testing the release version, the more difficult it is to eliminate the problem. At least one test is performed on the release version every week, this allows you to save potential troubleshooting time in a compact development cycle.

Do not delete the required release version.Code
This seems obvious, but it is a mistake that developers often make accidentally because the compiler will automatically exclude Macros in the code when compiling the release version, for example, assert and trace are automatically excluded in the release version. The problem is that the code you run in these macros is also deleted, which is a very dangerous thing J, for example:

Assert (m_imagelist.create (makeintresource (idb_images), 16, 1, RGB (255,255,255 )));

This code will not go wrong in the debug mode, and the image list will be automatically created. But what about the release version? Subsequent Use of the m_imagelist object will only cause the program crash !, Therefore, we recommend that you use logical operators for verification in the assert macro.

Rule 2: Do not place the code in the place where it is executed only in a certain compilation option. The use of the code inside the compilation option macro such as _ debug must not affect the use of the entire program.

Rule 3: Do not use rule 2 as the criterion to delete the assert macro. The assert macro is a useful tool, but it is easy to use incorrectly.

Bring the debug compilation mode closer to the release Mode
If your release version has problems caused by the code being automatically ruled out by the compiler, your problems may be reproduced through this method.

Some problems may be caused by predefined symbols between different compilation options. Therefore, you can change the predefined symbols in the compilation mode so that your debug mode is close to the release mode, observe whether errors are generated. The method for changing the pre-defined symbols of compilation is as follows:

Alt-F7 open the Project Settings, on the C ++/C page, select the "General" category and change the "_ debug" symbol to "ndebug ".
On the C ++/C page, select the "Preprocessor" type and add the pre-defined symbol "_ debug" to the "undefined symbols" column.
Recompile with "rebuild all"
If you use the above settings to reproduce the problems in the release compilation mode in debug mode, follow these steps to modify your code:

Find out all important execution statements in assert, or modify assert to verify.
Check all the code in "# ifdef _ debug" to exclude the code used in the release mode.
Find the trace to exclude all important execution statements. The trace is the same as the assert and is compiled only in debug mode.
If you corrected your problem in debug mode through the above modification, you can re-compile the release mode, which is very likely to solve the previous problem !.

Incorrect assumptions cause compilation mode errors
Do you often assume that your variables or objects are initially converted into a specified value (maybe 0 )? Do you assume that all your associated resources exist in the application? These are also the causes of different problems in debug and release modes.

Rule 4: Unless you initialize the variables in the Code, the above assumptions cannot be made, including global variables, automatic variables, application objects, and new objects.

This problem often occurs in the memory sequence. Remember to compare the two struct objects using memcmp for ease of use when using the struct, which works normally in the debug version, when the release version calculates an incorrect solution, it does not seem that an incorrect assumption can be made!

Rule 5: make sure all references to the deleted resource are deleted, for example, the definition in resource. h.

In software development, the initialization of variables and memory is different for different compilation versions. if you assume that the variable Initialization is 0, an exception occurs in the release mode of the Win9x system. Therefore, it is safer to explicitly clear 0 memory for all variables.

If you reference a deleted resource, your debug version works normally, but the release version may crash.

Do you believe in the compiler?
The compiler warning level has a considerable relationship with compilation noise.

By increasing the compiler warning level, you can increase the chance of program hidden problem exposure. generally, the warning level is set to "Level 3" or "Level 4 ". compile and resolve all warnings. This is a good suggestion for releasing the release application. this exposes many initialization problems and other potential errors that may cause problems in your application.

Rule 6: Set the compilation warning level to "Level 3" or "Level 4" before starting the project. Ensure that all warnings are cleared before registering the code !.

Summary Report
Debugging in compilation Mode
I have heard more than once that some VC developers say that debugging cannot be performed in the release mode. Fortunately, through corresponding settings, debugging can be performed in the release mode, therefore, it is just an absurd saying that is just a rumor.

Rule 7: Debug in release mode when all current methods are invalid.

You can debug the release mode. The first step is to open the symbol table:

Alt-F7 open the Project Settings, on the C ++/C page, select the "General" class, modify debug info setting to "program database ".
On the "Link" Page, select "Generate debug info ".
"Rebuild all"
These settings allow you to retain the symbol table in release mode. You can also consider the following settings:

Debug the release version application. You can disable the optimization option.
If you cannot set a breakpoint in the release mode, add the command "_ ASM {INT 3}" to stop your application (confirm to exclude the code when publishing the application ).
Several restrictions on debugging in release mode.

The biggest problem is that you cannot track the content of the MFC function because the release version of the MFC dynamic link library does not contain debugging information and symbol tables.
Same as above. To debug the called DLL, you must add the debugging information and symbol table to all of them.
The compiler generated the error code?
Sometimes you may find that the VC ++ compiler generates 'problematic Code', but frankly speaking, people usually complain too early. you can disable the optimization option in the release mode for testing.

If this operation solves your problem, there may be problems with your encoding habits. believe it or not, it is very likely that there is an ambiguous solution in your code or it seems to be correct. In some cases, it is also true. for example, the following code seems to be 'normal' In the debug mode, but errors will occur in the release mode!

# Include <stdio. h> int * func1 () {int retval = 5; Return & retval;} int main (INT argc, char * argv []) {printf ("% d \ n ", * func1 (); Return 0;} I believe that most programmers, especially beginners, are prone to such situations.

Rule 8: If Optimization Options in the release mode are disabled, your application can run normally, and activation of optimization options may cause problems, most of which are caused by your bad coding habits. this means you must carefully check your code and clear the incorrect assumptions, floating pointers, and so on. similarly, this tells you that in the debug mode and the release mode where optimization options are disabled, your application works normally because of the luck of the system. You must correct the hidden code, otherwise, it may cause huge losses in the future.

Rule 9: If you have thoroughly checked your code and have not found any problems, you 'd better open the optimization option one by one to limit the cause of the error to a certain range.

BTW-the above problem code is automatically detected by the C ++ compiler. If you have followed rule 6, you may have fixed these problems in the previous step.

Based on my development experience, the compiler rarely produces wrong code (of course, pay attention to the interface program boundary alignment problem ). generally, when using the template class, the vc6 compiler may produce an Assert error. In this case, you only need to update the patch to solve the problem.

Last thought
In daily coding, you only need to add a little more rigorous detection to effectively avoid the problem of the new debug-v-release mode. Below are some of my experiences.

1. Check out the code to be modified.

2. modify the code, exclude all warnings, and compile the debug and release versions.

3. test the new code in detail, that is, after debugging the new code segment in one step, enter the work code to ensure that the Code is correct.

4. Correct all problems.

5. Check in the new code after confirmation ).

6. Compile the code for registration and storage to ensure that the new registration code is integrated with other codes.

7. Test the code again.

8. Update the problem (You may find problems with the registration code)

Strictly follow the above steps to solve a large number of problems in the design and development process, and avoid new problems that are difficult to locate when the application is finally released.