Debugging Heap Corruption in Visual C++

所需积分/C币:1 2018-04-25 14:45:44 36KB PDF
5
收藏 收藏
举报

vc程序开发过程中,堆破坏后往往难以定位到问题,介绍跟踪与调试问题的方法。
Debugging Heap Corruption in Visual C++ Debugging Tools To perform this procedure you will use the debugging Tools for Windows, available for free download from the Microsoft WKD and Developer Tools web pages To find the download site, search the Web for a string similar to"Install Debugging Tools for Windows 32-bit Version"and download and install the following version or later, taking all defaults: Current Release version 6.6.7. 5- July 18, 2006" From the Debugging Tools for Windows, you will use the following programs WinDbg.exe: A heap-level debugging program similar to the visual C++ debugger Using Windbg, you can set breakpoints in source and assembly code display the values of variables, dump heap memory into a file, and analyze such a dump offline GFlags. exe: A heap debug program USing GFlags, you can establish standard, /full, or /dlls heap options that will force the operating system to generate access violations and corruption errors when your program overwrites heap memory. Specific WinDbg Commands You will use the following specific WinDbg commands and menu items, in addition to the familiar debugger commands of Go, Step Watch, and so on Command Meaning File, then Open Executable Brings up your program inside the WinDbg debugger This allows you to debug the initialization phases of your program's execution However, the program's memory usage is somewhat different from that of ordinary execution File, then Attach to a process Links the Win Dbg debugger to your program after it has started running. You cannot debug the InitialIzation phases of your programs execution However, the program's memory usage is more similar to that of ordinary execution than if you had brought up the program inside the debugger File, then Symbol File Path Directs the WinDbg debugger to the directories il which the VC++ compiler has placed the debug ( pdb) files that your program needs to display symbols, such as subprogram names File. then source file path Directs the WinDbg debugger to the directories which the source files for your program reside symfix+ Turns on access to the microsoft online symbol server.The resulting path appears in the Symbol File Debugging Heap Corruption in Visual C++ Command Meaning g Path. You must be connected to the Web for this command to work dump/ma Filename. dmp Dumps heap memory in mini-dump format. The /ma option means it is a mini-dump(m.) containing all a)information needed to reconstruct the state of the program when the dump occurred File,then Open Crash Dump Directs the Win Dbg debugger to a dump file produced by the dump command analyze -V Analyzes the contents of a dump file produced by the dump command The -v stands for verbose information Specific GFlags Commands You will use the following specific GFlags commands Command Meaning GFlags/p Displays the state of the page heap options GFlags/p/enable Program. exe Enables standard heap options for Program.exe GFlags inserts a suffix pattern into the heap after each allocation by your program. Y our program will use somewhat more memory and run somewhat slower than normal GFlags/p/enable Program.exe Enables full heap options for Program. ere GFlags /full inserts an entire page of protected memory into the heap after each allocation by your program. Your program will use much more memory and run much slower than normal GFlags/p/enable Program.exe Enables standard heap options for Program. exe and /dlls Library/.dll, Library2. d I,.. all dynamic link libraries(DLLs)not listed after the dlls option. In addition, it enables full heap options for the listed dll or dlLs. Separate items in the DLL list by commas. Your program will run faster and use less memory than it would if you had used the/full option GFlags/p/enable program.exe Enables standard heap options for program.exe.In Debugging Heap Corruption in Visual C++ Command Meaning /debug Debugger.exe to automatically run if the program crashes. the ser addition, it designates Debugger. exe as the debugge debug option comes after/full or /dlls in the command line GFlags/p/disable Program. exe Disables all heap options for Program.exe.You should do this at the end of cach debug session Otherwise, every user of the program after you will experience slow performance GFlags Invokes a dialog box that allows you to review and change the current GFlags settings Preparation for Debugging You must prepare the debugging environment before you run the program. In particular, you must install the debugging tools, compile your program with the correct options, and configure the debugging tools to run with your program Program Installation and Compilation 1. Install Microsoft Debugging Tools for Windows as indicated in Debugging Tools 2. Add the path to the debugging tools for windows directory to your system path via ControlPanel, then System then advanced then Environment variables. This will allow you to run debugging Tools programs from a command line 3. Compile your program and any dlls it uses with the following compiler options /Od /Oi These options turn off compiler optimization and store debug symbols in pab files in the same directory as the. exe file, usually the debug directory First-Time WinDbg Options You should execute the following one-time tasks the first time you run your program with WinDbg 1. Start WinDbg.exe 2. If you can attach WinDbg to your program after it has started, start your program and attach Windbg to the process by clicking on File, then Attach to a Process and following the prompts. Otherwise, run your program from WinDbg using File, then Open Executable likewise Debugging Heap Corruption in Visual C++ 3. In the command line at the bottom of the Command window, type the following command symfix+ This will connect this and future WinDbg sessions associated with this program to the microsoft symbol server 4. Click on File, then Symbol File Path and browse to the directory where your program's, exe file resides. Click again and browse to the directory where any DLLS you are using reside 5. Click on File, then Source File Path and browse to the directory where your program 's source files reside. Click again and browse to the directory where the source files for any DLLs you are using reside. 6. Exit WinDbg, clicking Yes to store the WinDbg options associated with this program You will set other options from the command line before you run the program and from the Windbg interface after you have attached to the program Live Debugging A live debugging session has three main parts, executed iteratively as you debug 1. Setting gFlags options 2. Running the program to a breakpoint 3. Analyzing the program state at the breakpoint As a rule, you should plan at least two iterations, one with standard heap options and one with either the /full or the /dlls options. The example program in the appendix is small enough to allow you to use the /full option. Normally you will use the/dlls option Note that you must set up all gflags options before you run your program. When the system starts your program, it uses whatever GFlags options were set at that time and does not change them until the run is finished Standard Heap Options A session with standard heap options would go as follows 1. Set standard heap options GFlags/p/enable Program.exe 2. Invoke winDbg. exe. 3. Run Program. exe from Win Dbg using file, then Open Executable. If this were a program that brought up a command window or a dialog box that waited for user Debugging Heap Corruption in Visual C++ 7 input. you could also run it from the command line or via windows and then attach Win dbg to it by using File, then Attach to a Process 4. Click View, then Call stack to display the call stack 5. Click windbg then go from the toolbar 6. Wait for an error to occur. The standard heap options cause the system to place a suffix pattern after each allocation When your program attempts to delete the allocation, the system will check the suffix pattern, and if it has been overwritten, the system will raise an error The symptom might be an error popup, an Application Verify Stop, an Access Violation, a Memory Check Error, or any other error type severe enough to force the operation system to halt execution You may be able to find out why the memory is being corrupted by examining the error message, the contents of the registers and memory at various levels in the call stack, and the corresponding source and assembly-language code 7. Click Stop Debugging in the Win Dbg toolbar This will halt the program and empty the debug window 8. Clear the heap options. If you do not do this every user of the program after you will experience slow performance GFlags ip/disable Program.exe Full or DLLs Heap Options From the stack trace, you've discovered where the object was deleted, though not necessarily what allocated the memory or what corrupted it you have developed some notion of where it might have been created and how it was processed You can use this information to guide your search for a solution 1. Set/full or/dlls heap options. For a very small program, you can use /full heap options, as follows GFlags/p/enable Program. exe/full For more complex code, you would use /dlls options, as follows GFlags ip/enable Program. exe /ds Library /. dll, Library 2.dll, 2. Invoke winDbg. exe 3. Run Program. exe from WinDbg using File, then Load executable 4. Click View, then Call stack to display the call stack 5. Click WinDbg, then Go from the toolbar Debugging Heap Corruption in Visual C++ 6. Wait for an error to occur. The /full and /dlls heap options cause the system to place a full page of protected memory after each allocation from the designated scope or scopes. For the/dlls options, the system places a suffix pattern after each allocation from the remaining scopes When your program attempts to write into the protected memory the system will raise an error. The symptom might be an error popup, an Application Verify Stop an Access Violation, a Memory Check Error, or any other error type severe enough to force the operation system to halt execution. Note that the system will raise errors with /full or/dlls heap options that it will not raise with standard heap options You may be able to find out why the memory is being corrupted by examining the error message, the contents of the registers and memory at various levels in the call stack, and the corresponding source and assembly-language code 7. Click Stop Debugging in the Win Dbg toolbar. This will halt th e program an empty the debug window 8. Clear the heap options GFlags/p/disable program.exe Postmortem Debugging You prepare and execute postmortem debugging in much the same way you prepare for live debugging, including settings for GFlags. The main difference is that you do not run the program in the debugger or attach the debugger to the program after it starts. Instead you run the program as intended, but use GFlags to designate a debugger that the system will attach to the program if there is an error. The advantage of this procedure is that yo can minimize the effect upon program execution of your preparations for debugging 1. Set standard heap options with a designated debugger: GFlags/p /enable Program. exe /debug Win Dbg. exe 2. Run your program 3. Wait for an error to occur. The error might be an Application Verify Stop, an Access Violation, a Memory Check error, or any other error type severe enough to force the operation system to attach the debugger to the process and bring it up at a breakpoint. Then you can either analyze the error online as in any other debug session or evaluate the error offline To evaluate the error offline, you can pull a memory dump by typing the following into the WinDbg command line Debugging Heap Corruption in Visual C++ dump/ma Filename. dmp 4. Click Stop Debugging in the WinDbg toolbar. This will halt the program and empty the debug window 5. Clear the heap options GFlags/p/disable Program.exe Analyzing a Memory Dump If you have pulled a memory dump using the dump command, you can load and analyze it as follows 1. Invoke Win Dbg. exe and set up symbol paths and source file paths as above 2. Load the memory dump file by File, then Open Crash Dump 3. Analyze the memory dump by typing the following command into the command window l analyze-v The !analyze command will produce a verbose stack trace and an error exception, much like those that Win Dbg produces when you are debugging online. The main difference is that you cannot run the program and somctimes lack complete access to runtime variables References The key reference material for the Microsoft debugging Tools for Windows is the online help, accessible from the windbg help menu. See in particular the following Example 12: Using Page Heap verification to Find a bug · GFlags Commands Specific Exceptions · Create Dump file These tools and the Debugging Tools for Windows themselves implement many other useful features. To find out more about them, consult Debugging Help from Start, then Debugging Tools for Windows The Microsoft web site contains a great deal of useful information about debugging Windows programs. Search on"Debugging Tools for Windows You may also wish to investigate commercially-available tools such as purify and Bounds Checker. For more information on these tools, Google on"Rational purify and Debugging Heap Corruption in Visual C++ 10 Dev Partner Studio". For more on heap debugging in general, Google on"heap debugging Example Program As an example, you may set up the following program, which contains an out-of-range array error. an oversized structure cast error and a premature delete error 1. Create a Win32 Console application project named ConsoleExe. Do not cr Win32 Application. ConsoleExe uses standard I/O. which requires a dos eate a window 2. Copy the code at the end of this appendix into ConsoleExe cpp in place of the existing main program 3. Compile and link the ConsoleExe application with the compiler options /Od/Oi 4. At this point, you have three alternatives: (a) run it from the command line and attach Win dbg to it as it waits for input; (b) start it from WinDbg; or(c)use the /debug Win Dbg. exe option to bring up the debugger on an error You can then observe how the various heap debug options affect the behavior of the program and that of the debugger Example Program Code / ConsoleEXE cpp: Defires the entry point for the console // application #include stdafx. h'r #include <stdio. h> include <stdlib. h> const int cisize =5; typedef struct SmlallStruct short shshortl short shshort2 J Smallstruct typedef struct Bigstruct long Longl; long llong 2 Bigstruct void Arrayoverruncrash(void)i void oversizedcastCrash(void)i void PrematureDeleteCrash:(void)

...展开详情
试读 12P Debugging Heap Corruption in Visual C++
立即下载
限时抽奖 低至0.43元/次
身份认证后 购VIP低至7折
一个资源只可评论一次,评论内容不能少于5个字
您会向同学/朋友/同事推荐我们的CSDN下载吗?
谢谢参与!您的真实评价是我们改进的动力~
关注 私信
上传资源赚钱or赚积分
最新推荐
Debugging Heap Corruption in Visual C++ 1积分/C币 立即下载
1/12
Debugging Heap Corruption in Visual C++第1页
Debugging Heap Corruption in Visual C++第2页
Debugging Heap Corruption in Visual C++第3页

试读结束, 可继续读1页

1积分/C币 立即下载