Debug Release version application
introduction
If you encounter a common error during your development, you may not run normally and the debug version is running correctly, then I recommend you to read this article: Because not as you think, the Release version guarantees your app. You can run like the Debug version.
If you have already completed the Release version test after the development phase is completed, it has never been tested for a period of time, but when you test, you find a problem, then please see our debug rules 1:
Rules 1: Regularity regularly performs the general test of DEBUG and RELEASE versions of development software.
The longer the Release version is longer, the greater the difficulty of the rule, at least once a weekly test per week, which can save you potential troubles during a compact development cycle.
Don't delete the code required by the Release version
This seems to be obvious, but it is a mistake of developers unintentionally, because the compiler compiles the Release version, take the initiative to exclude macros existing in the code, such as Assert and Trace are automatically excluded, The problem caused by this is that the code you run in these macros is also removed, which is very dangerous. J, for example:
ASSERT (M_Imagelist.create (MakeintResource (IDB_IMAGES), 16, 1, RGB (255, 255, 255)));
Such a code will not be wrong in the debug mode, and the image list is also automatically created, however it is in the Release version? Subsequent use m_imagelist objects only cause the program's Crash !, so assert is try to use the logical operator as a verification.
Rule 2: Do not place the code in the place implemented in a certain compilation option, and the code for the use of _debug and other compilation options must not affect the use of the entire program.
Rules 3: Do not use rule 2 as the evaluation criteria to delete the Assert macro, the Assert Macro is a useful tool, but it is easy to use.
Close Release mode compilation mode
If your Release version exists, the code is automatically excluded by the code, then your problem may be reproduced by this method.
Some problems may be caused by predefined symbols between different compilation options, so you can change the predefined symbols in compilation mode, so that your debug mode is close to the Release mode, observe whether the error is generated, change compile predefined symbols Methods as below:
ALT-F7 Opens the project settings, in the C / C page, select the "General" category, change the "_debug" symbol "nDebug".
In the C / C page, select the "PreProcessor" category to add a predefined symbol "_debug" to the undefined symbols.
Re-compile using "Rebuild All"
If you are set above, your problem in Release Compilation Mode is reproduced in Debug mode, then please modify your code according to the following steps:
Find Assert exclude all important execution statements, or modify Assert to Verify.
Check all the code in "#ifdef _debug" to exclude the code used by the Release mode.
Find TRACE exclude all important execution statements. TRACE and ASSERT are only compiled in Debug mode.
If you modify the problem in debug mode by modifying, you can recompile the Release mode, it is very likely that you can solve the problem of previous existence! .
Error assumption causes compilation mode errors
Whether you regularly assume that your variable or object is initially tried into a specified value (may 0)? Do you assume that all the resources you associate exist in the application? These are also the causes of different problems in Debug and Release mode. Rule 4: Unless you initialize the variables in your code, you can't make a hypothesis. Include global variables, automatic variables, application objects, and New objects.
This situation often occurs in the memory order, remember to use the structure when using the structure, compare two structural objects use MEMCMP, and work in the debug version, and the Release version calculates the error solution, it is true Can't make mistakes!
Rules 5: Make sure all references to delete resources are deleted, such as the definition in resource.h.
Different compilation versions are different for the initialization of variables and memory. If you assume that the variable is initialized to 0, an abnormal phenomenon occurs in the release mode of the Win9x system. Therefore, all variables, memory explicit clear 0 is a more secure approach.
If you reference resources that have been deleted, your debug version can work normally, but the release version may Crash.
Do you believe in compilers?
The compiler warning level and compilation noise have a considerable relationship.
By increasing the compiler warning level to increase the opportunity to hide the exposure of the program. Typically set the warning level in "Level 3" or "Level 4". Compile and resolve all warnings, this is a good suggestion for release the Release version application. This can expose a lot of initialization issues and other potential errors that make your application problems.
Rules 6: Before starting the project, set the compilation warning level in "Level 3" or "Level 4", make sure all warnings before registering the code! .
summary report
Debugging in compilation mode
I have heard some VC developers say that the Release mode cannot be commissioned below. Fortunately, through the corresponding settings, you can debug in the Release mode, so that it is just a ridiculous saying.
Rule 7: When all the methods in front are invalid, debug below the Release mode.
Release mode can debug, the first step is to open the symbol table:
ALT-F7 Opens the project settings, in the C / C page, select the "General" class, modify Debug Info Setting as "Program Database".
In the "LINK" page, select "Generate Debug Info".
Rebuild All
These settings will allow you to keep the symbol table in Release mode, you can also consider the following settings:
Debug Release version application, you can close the optimized option.
If you cannot set a breakpoint in the Release mode, add an instruction "__ASM {INT 3}" can be your application to stop stop (determined to exclude these code when the application is released).
Several restrictions on the Release mode for debugging.
The biggest problem is that you cannot track the MFC function, because the Release version of the MFC dynamic link library does not contain debugging information and symbolic tables.
Also, you want to debug the DLL that calls the call, you must add all debug information and symbolic tables.
The compiler generates an error code?
Perhaps sometimes you will find the VC compiler to generate 'problem code', but frankly, people usually complain too early. You can close the optimization option below to test.
If this operation solves your problem, you may have problems with your coding habits. Letter do not believe in you, extremely likely to have ambiguous two can solve or seem correctness, and some conditions are also correct. Example, the following code seems to be 'normal' in Debug mode, but it will be wrong in Release mode! #include
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, easily encounter such situations.
Rule 8: If you turn off the Release mode Optimization option to make your application running normally, and open an optimized option, there is a problem, however, is caused by your bad coding habits. This means you must carefully check your code. Clean out those false hypothesis, hanging pointers, etc. Isometrically tell you, in the Release mode of Debug mode and closing the Optimization option, your application is working properly because the system implied, you must start more hidden dangers The code, otherwise it may cause huge losses in the future.
Rule 9: If you have already completely checked your code, there is no problem, then you'd better open the optimization option one by one will result in an error.
BTW - The above problem code is automatically detected by the C compiler. If you have followed rule 6 You may have solved these problems in the front link.
With my development experience, the compiler will raise the wrong code (of course, pay attention to the problem of interface program boundary alignment). Usually the VC6 compiler is usually asserted assert error, this situation you only need to update The patch can be resolved.
Last thoughts
Just add a slight increase in rigorous detection in daily encoding, it is effective to avoid the generation of new debug -v- transase mode, the following is my experience.
1. Remove the code that needs to be modified.
2. Modify the code to exclude all warnings, compile the debug and the release version.
3. Test the new code in detail, ready to enter the work code after the new code segment, make sure the code is correct.
4. Correct all questions.
5. Check IN after confirming the error (Check IN).
6. A new compilation of the code to the library to ensure that the new registration code is integrated with other code.
7. Re-detail test code.
8. Correct new issues (maybe you can find issues with the registration of the library code)
Strictly follow the steps, you can solve a large number of problems during the design development process, avoiding new difficult positioning problems when the application is released.
postscript
This article encounters the release version of the Release version application in my development process. It is a matter from CodeProject. It has come to CodeProject. After himself, it has become an article suitable for domestic developers, hoping to everyone. Useful, thank you!
