Debug and Release version differences and commissioning related issues:
I. Memory allocation problem
1. Variables are not initialized. The following program runs very well in Debug.
Thing * Search (Thing * Something)
Bool Found;
For (int i = 0; i { IF (wherever [i] -> Field == Something-> Field) {/ * Found IT * / Found = True; Break; } / * Found IT * / } IF (Found) Return whatver [i]; Else Return NULL; And in Release is not, because DEBUG will automatically initialize FOUND = FALSE, and it will not be in the Release version. So initialize the variables, classes, or structures as much as possible. 2. Question of data overflow Such as: char buffer [10]; Int counter; LSTRCPY (Buffer, "Abcdefghik"); In the debug version of the buffer NULL covers the high level of the Counter, but unless the Counter> 16M, there is no problem. However, in the Release version, the Counter may be placed in the register so that null covers the space below the buffer, which may be the return address of the function, which will cause Access Error. 3. The DEBUG version and the RELEASE version of the memory allocation method are different. If you apply for ELE for 6 * sizeof (dword) = 24bytes in debug version, it is actually assigned to you. In 8bytes), if you write ELE [6] in Debug, there may be no problem, and in the Release version, there is Access Violate. Ii. Assert and Verify 1. Assert is not compiled in the Release version. Assert macro is defined #ifdef _Debug #define assert (x) IF ((x) == 0) Report_assert_failure () #ELSE #define assert (x) #ENDIF In fact, it is more complicated, but it is insignificant. If you add a code you must have in these statements such as Assert (pnewobj = new cmyclass); PNEWOBJ-> myfunction (); This time, the PNEWOBJ in the Release version will not be assigned to space. So when executed to the next statement, the program will report the program to perform an illegal operation error. At this time you can use Verify: #ifdef _Debug #define verify (x) IF ((x) == 0) Report_assert_failure () #ELSE #define verify (x) (x) #ENDIF In this case, the code can be executed in the release version. Iii. Parameter problem: The processing function of custom messages must be defined as follows: AFX_MSG LRESULT ONMYMESSAGE (WPARAM, LPARAM); The return value must be the HRESULT type, otherwise Debug will pass, and Release error IV. Memory Allocation Ensure the unity of data creation and clearing: If a DLL provides a function capable of creating data, then this DLL should provide a function to destroy this data. The creation and clearing of the data should be at the same level. V. DLL disaster The inconsistency image caused by different versions of DLL is called "DLL Hell" (DLL Hell), and even Microsoft himself said (http://msdn.microsoft.com/library/techart/dllDanger1.htm) ). Please pay attention when your program uses your own DLL: 1. Cannot use the DLL of Debug and Release version together. Debug is a debug version, and the Release version is a release version. The solution is to put DEBUG and RELEASE programs in the main program's Debug and Release directory. 2. Don't think that the static connection library will solve the problem, which will only make the situation worse. Debugging in the Release board: 1. Change assert () to verify (). Find the code defined in "#ifDef _debug", if you need these code in the Release version, move them to the definition. Find TRACE (...), because these codes are not compiled in Release. Please carefully check if the code you need in Release is not cheap. 2. Initialization of variables, there is such differences between different systems, or between the Debug / Release version, so initialize the variables. 3. Is there a warning when compiling? Set the warning level to 3 or 4, then ensure that there is no warning when compiling. VII. Optimization options in the "C / C" project in Project Settings "change to disbale (debug). The compiler can result in many unexpected errors, please refer to http://www.pgh.net/~newcomer/ Debug_release.htm 1. In addition to the Release version software can also debug, please do the following changes: Set "category" to "General" under "C / C" in "Project Settings" and set "Debug Info" to "Program Database". In the "LINK" project, "Generate Debug Info" check box is selected. Rebuild All Some restrictions arising from this way: The value of variables in the MFC DLL cannot be obtained. All DLL projects used in this software must be changed. another: MS BUG: A technical document of MS indicates that in VC5's "Maximize Speed" optimization option for DLL is not fully supported, so this will cause memory errors and cause the program to crash. 2. www.sysinternals.com has a program debugview to capture output OutputDebugString output, and after running (Estimated to be SYSTEM Debugger), you can view the output of all programs OutputDebugString. Since then, you can get rid of VC to run your program and watch debug information. 3. There is a static code check tool called Gimpel Lint, which is said to be better. http://www.gimpel.com is not too much. references: 1) http: // 呜呜. Cygnus-software.com / papers / release_debugging.html2) http: // 呜呜 呜 核 .NET / ~ Newcomer / debug_release.htm
