After a year, I have done two projects, all of which are developed on someone else's code, suffering: bug is too much. There are more than half of this year to change someone's BUG, and have accumulated some experience and share it with you. Most of my approach come from "Windows Program Debug" (English name Debugging Windows Programs). That book has spent a lot of ways, I only picked myself the greatest for myself:
1. Debug memory damage.
The performance of this bug is uncertain, and the collapse is unique. This kind of bug has a total of 2 times, and it takes a long time every time, especially the second time, spent three days. The reason is that heap is destroyed.
My method is this: In the case where there may be problems, add the inspection of the heap, with the following code:
// Get The Current State of the Flag
// and store it in a Temporary Variable
INT TMPFLAG = _CRTSETDBGFLAG (_CRTDBG_REPORT_FLAG);
// Turn On (OR) - Keep Freed Memory Blocks in The
//HEAP's Linked List and Mark Them As Freed
TMPFLAG | = __CRTDBG_CHECK_ALWAYS_DF;
// set the new state for the flag
_CRTSETDBGFLAG (TMPFLAG);
INT * nn = new int;
DELETE NN;
// Turn Off (AND) - Prevent _CrtcheckMemory from PREVENT _CRTCHECKMEMORY
// Being Called At Every Allocation Request, IT Will Cause Much Time
TMPFLAG & = ~ _CRTDBG_CHECK_ALWAYS_DF;
// set the new state for the flag
_CRTSETDBGFLAG (TMPFLAG);
If the previous stack is already broken, the program (Debug version) will be interrupted in the distribution of memory, here is int * nn = new int;
The code for the first destroying pile is like this:
Typedef struct aa
{
Int a;
} Aa;
AA S [N];
INT i = 0;
For (i = 0; i { ... ... For (i = 0; i ... ... s [i] .a = 0; } I use I to do a loop variable inside and outside, so that the pile is destroyed. The second code is more concealed. I first use the Map file to find the collapse of the crash, but a look is a Window's API, let go, and then use the above method, and position it to the API: getFileAttributex (Szfile Getfileexinfostandard, & Attributes; It is found that the parameter of the SZFILE is a problem. It is an illegal file name, and then calls the legal check of the file name before calling this API. Oh, it's really this API, it seems that we still can't let Microsoft do everything. 2. Find Memory Leak You can find Memory Leak through memory distribution numbers, the method is like this (I used to write MSDN, I don't translate): You can see the information below in Your VC Output Window iF the app home memory! DUMPING OBJECTS -> {18} Normal Block AT 0x00780E80, 64 BYTES Long. Data: <> CD CD CD CD CD CD CD CD CD CD CD CD CD Object Dump Complete. IF you can not see the dump information in vc, you can add the code to the file crtdbg.h: #ifdef _Debug #define _crtdbg_map_alloc #define _inc_malloc #include // Custom Functions Declaration (ATL BETA VERSION ProBLEMS) EXTERN "C" { Void * __cdecl _alloca (size_t); #define alloca _alloca } #ENDIF As you can see, _crtdumpMemoryleaks gives You Much more useful information when _crtdbg_map_alloc is defined. Withuc defined, The Display shows you: the memory allocation number (inside the curly braces) .the type of block (normal, client, or CRT) .the memory location in hexadecimal form.the size of the block in bytes.the contents of the first 16 bytes (also in hexadecimal ). You can run your program twice in the same way, then you can find that the memory allocation number of the leaked memory is always the same, so you can use the memory allocation number to find the memory leak; directly to say, you can break The Program by Memory Allocation Number. The Below Is Taken from Msdn (Detecting and Isolating Memory Leaks Using Microsoft Visual C ) Setting a Breakpoint On A Memory Allocation Number The file name and line number in the memory leak report tell you where leaked memory is allocated, but knowing where the memory is allocated is not always sufficient to identify the problem. Often an allocation will be called many times during a run of the program, but it may leak memory only on certain calls. to identify the problem, you must know not only where the leaked memory is allocated but also the conditions under which the leak occurs. The piece of information that makes it possible for you to do this is the memory allocation number. This is the number that appears in curly braces, after the file name and line number when those are displayed. For example, in the following output, "18" is the memory allocation number. It means the leaked memory is The 18th Block of Memory Allocated in Your Program.dtected Memory Leaks! DUMPING OBJECTS -> C: / Program Files / Visual Studio / MyProjects / LeakTest / LeakTest.cpp (20): {18} Normal Block AT 0x00780E80, 64 bytes long. Data: <> CD CD CD CD CD CD CD CD CD CD CD CD CD Object Dump Complete. The CRT library counts all memory blocks allocated during a run of the program, including memory allocated by the CRT library itself or by other libraries, such as MFC. Therefore, an object with allocation number n will be the nth object allocated in your program but May Not Be The Nth Object Allocated by your code. (in Most Cases, It Will NOT BE.) You can use the allocation number to set a breakpoint at the location where memory is allocated. To do this, set a location breakpoint near the start of your program. When your program breaks at that point, you can set such a memory allocation breakpoint from THE Qickwatch Dialog Box or The Watch Window, for Exple, Type The Following Expression In The Name Column: _CRTBREAKALLOC IF you are using the multithreaded Dynamic-Link Library (DLL) Version of The Crt Library, You Must Include The Context Operator, AS Shown Here: {, MSVCRTD.DLL} _CRTBreakalloc Now, press RETURN. The debugger evaluates the call and places the result in the Value column. This value will be -1 if you have not set any breakpoints on memory allocations. Replace the value in the Value column with the allocation number of the memory Allocation Where You Want to Break-for Example, 18 to Break At The Allocation Shown in The Output Earlier. After you set breakpoints on the memory allocations in which you are interested, you can continue debugging. Be careful to run the program under the same conditions as the previous run so the allocation order does not change. When your program breaks at the specified memory allocation , you can look at the Call Stack window and other debugger information to determine the conditions under which the memory was allocated. If necessary, you can continue execution of the program from that point to see what happens to the object and perhaps determine why it is NOT Properly Deallocated. (Setting a Data Breakpoint on The Object May Be Helpful.) Although it is usually easier to set memory allocation breakpoints in the debugger, you can set them in your code, if you prefer To set a memory allocation breakpoint in your code, add a line like this (for the 18th memory allocation):. _ CrtBreakAlloc = 18; As an alternative, you can use the _crtsetbreakalloc function, Which Has The Same Effect: _CRTSETBREAKALLOC (18); As to your APP, you must rename the file msvcrtd.dll to let the APP use the dll file in the folder System32. You should add {,, msvcrtd.dll} _crtBreakAlloc to the Watch. You'd use Step Into and set the Breakpoint. 3. Cross process debugging. For example, two programs app1 and app2, the app1 is up to the app2, this time you want to debug App2. You can do this, in the appropriate place in the app2 in initInstance (), add an Assert (false); let App2 stop, then use VC Attach passed, you can go to the CPP corresponding to the app2 to the point. "Windows Program Debugging" also has a lot of ways: such as high-grade breakpoints, remote debugging, MAP files, etc., are very useful methods, I am listed here, I have not awkward. For the principle, I hope everyone will read the book and msdn. One must have a high quality code, plus more inspections, may save others three days. If you have an inappropriate place, I hope everyone will correct it.
