VC中的一些调试技巧Word文件下载.docx

1、43:26点击：6799 毕业快一年，做了2个项目，都是在别人的代码上作开发，苦不堪言：bug 实在是太多。这一年中有大半的时间是在改别人的bug, 也积累了一些经验，和大家分享。我的方法大多数都来自Windows程序调试（英文名 Debugging Windows Programs）。那本书里讲了很多方法，我只挑对我自己帮助最大的：1 调试内存破坏。这种bug的表现就是不定时，不定地方的崩溃。这种bug我一共碰到2次，每一次都花了很长时间，尤其是第二次，花了大家三天时间。其原因是堆（heap）被破坏掉了。我的方法是这样的：在可能出现问题的地方加上对堆的检查，用如下代码：/ Get the c

2、urrent state of the flag/ and store it in a temporary variableint tmpFlag = _CrtSetDbgFlag（ _CRTDBG_REPORT_FLAG ）;/ Turn On （OR） - Keep freed memory blocks in the/ heaps linked list and mark them as freedtmpFlag |= _CRTDBG_CHECK_ALWAYS_DF;/ Set the new state for the flag_CrtSetDbgFlag（ tmpFlag ）;int

3、 *nn =new int;delete nn;/ Turn Off （AND） - prevent _CrtCheckMemory from/ being called at every allocation request，It will cause much timetmpFlag &= _CRTDBG_CHECK_ALWAYS_DF;如果之前堆已经坏掉了，那么程序（Debug版）就会在分配内存的地方中断，在这儿是int *nn =new int; 第一次破坏堆的代码是这样：typedef struct aa int a; AA;AA sn;int i = 0;for（i=0;i18 n

4、ormal block at 0x00780E80, 64 bytes long. Data: CD CD CD 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 declarati

5、on （ATL + BETA version problems）extern Cvoid * _cdecl _alloca（size_t）;#define alloca _alloca#endifAs you can see, _CrtDumpMemoryLeaks gives you much more useful information when _CRTDBG_MAP_ALLOC is defined. Without _CRTDBG_MAP_ALLOC defined, the display shows you: the memory allocation number （insi

6、de 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

7、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 Memo

8、ry Allocation NumberThe 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 lea

9、k 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 appear

10、s 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.C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp（20）

11、 : 18 normal block at 0x00780E80, 64 bytes long.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 y

12、our 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 po

13、int, you can set such a memory allocation breakpoint from the QuickWatch dialog box or the Watch window. In the Watch window, for example, type the following expression in the Name column:_crtBreakAllocIf you are using the multithreaded dynamic-link library （DLL） version of the CRT library （the /MD option）, you must include the context operator, as shown here:,msvcrtd.dll_crtBreakAllocNow