Enhanced memory leak detection tool-VLD 1.9 D.

/*
Recently, I often encountered a memory leak problem. Generally, this problem is quite annoying. I found a tool on the Internet-VLD. By the way, I translated some of his documents.
Memory leak detection tool (visual leak detector 1.9d (Beta ))
Translation: xroy
2008-02-14, CD.

Keyword: Memory leakage, VLD.
*/

Introduction: (not translated)
Visual c ++ provides built-in memory leak detection, but its capabilities are minimal at best. this memory leak detector was created as a free alternative to the built-in Memory Leak Detector provided with Visual C ++. here are some of visual leak detector's
Features, none of which exist in the built-in detector:

* Provides a complete stack trace for each leaked block, including source file and line number information when available.
* Detects most, if not all, types of In-process memory leaks including com-based leaks, and pure Win32 heap-based leaks.
* Selected modules (DLLs or even the main exe) can be excluded from leak detection.
* Provides complete data dumps (in Hex and ASCII) of leaked blocks.
* Customizable Memory Leak Report: can be saved to a file or sent to the debugger and can include a variable level of detail.

Other after-market leak detectors for Visual C ++ are already available. but most of the really popular ones, like purify and boundschecker, are very expensive. A few free alternatives exist, but they're often too intrusive, restrictive, or unreliable. visual
Leak detector is currently the only freely available memory leak detector for Visual C ++ that provides all of the above Professional-level features packaged neatly in an easy-to-use library.

Visual leak detector is licensed free of charge as a service to the Windows developer community. If you find it to be useful and wowould like to just say "thanks! ", Or you think it stinks and wocould like to say" This thing sucks! ", Please feel free to drop
Me a note. Or, if you 'd prefer, you can contribute a small donation. Both are very appreciated.

Usage:

Follow these steps to use VLD in your project:
1. in the C/C ++ source file of your program, at least one file contains VLD. h. it does not matter which source file it contains. Similarly, the sequence of containing this header file and other containing statements is not important, except for pre-compiled header files, it should be placed at the beginning.
2. If one or more DLL files exist in your project and you want to use VLD in these DLL files, the condition '1' should be met in each DLL ';
3. Compile to debug version
 
Note: It is not used in earlier versions of VLD. Now, it can be included in multiple source files or into a common header file that is contained multiple times. no matter how many source files contain VLD. h. Only one VLD copy will be loaded into the process.
 

VLD detects Memory leakage in your program whenever you run the debug version. when you run your program in the VC debugger, when your program memory leaks, a report of all detected memory leaks will be displayed in the output window of the debugger (this report can also be saved to a file, see the reportfile item in the configuration file ). in the error report (which should be in the debugger), double-click the row number of a source file to jump to the line with errors in the source file in the code editor.
Note: When you compile a release program, VLD will not be linked to your executable program, VLD can be safely discarded. This will not cause any performance degradation or other overhead for your program.

Configuration Options:
Some configuration parameters control the action of VLD. these configuration parameters are stored in VLD. ini. by default, this file should be in the VLD installation directory. however, this configuration file can also be copied to the working directory of the program. In this case, debugging the program works under the working directory.

------------------------------------------------------------
Aggregateduplicates

Generally, the VLD will detail each memory leak block. setting this option to yes will enable the VLD to bring together all the leaks, share the same size and call stack, and provide a single output in the report. only the first leaked block will be detailed. none of them will be displayed. the alternative is a display of a total of leaked numbers and matching sizes and call stacks.

----------------------------------------------------------
Forceincludemodules
In some rare cases, it may be necessary to include a module in leak detection, but it may not contain VLD. h to any source file. in this case, this operation can use force VLD to include these modules into memory detection. list the names of these modules (DLL) so that they are forcibly included in the leak detection. if you use this option, you should set VLD. link lib to your project.
 
Note: This option is used only when it is absolutely necessary. in some cases, using this option may lead to unpredictable behavior, including reporting failure or/or crash. it is best not to use this option unless you are sure you know what you are doing.

----------------------------------------------------------
Maxdatadump

Set the test parameter to an integer to limit the data size displayed in the memory leak dump. when the memory size of this value byte has been dumped, the dump will be stopped. this applies to any leaking block that is too large or the output window of the debugger is very messy. set this parameter to 0, indicating no dumping.

----------------------------------------------------------
Maxtraceframes

By default, VLD tracks the call stack as far as possible. in your debugging program, each tracked frame is appended to an additional overhead (both CPU time and memory usage ). if you want to limit these overhead, you can define this macro as a numerical value. when the number of frames to be tracked reaches this threshold, the stack tracing will be stopped. this frame count may contain some "internal" frames. by default, they are not displayed in the debugger window (see traceinternalframes below ). in some cases, three or four "internal" frames may exist at the beginning of the call stack.
When using this macro, pay attention to this. Otherwise, you may not see the expected frame.

----------------------------------------------------------
Reportencoding

When the Memory Leak report is saved to a file, the report can be unicdoe rather than the default ASCII code. this is useful when the Memory Leak contains Unicode text. set this parameter to "unicdoe" to generate a unicoed encoding report.

----------------------------------------------------------
Reportfile

Use this option to specify the location and name of the target report file. If this parameter is not specified, the report file will be generated in the working directory named "memory_leak_report.txt ".

----------------------------------------------------------
Reportto

This parameter is used to specify where the report is appended. It can be one of the following parameters: "Debugger" (default), "file" or "both ".

----------------------------------------------------------
Selftest

VLD has its own ability to detect leakage. this function is always activated. at any time you run VLD and append it to your program to check for memory leaks. It also checks itself. set this parameter to "on" to force VLD to intentionally leak a piece of memory: a 21-character block with the content of "Memory Leak self-test" is filled in the leaked block. this ensures a way to test the VLD self-check capability. verify whether it works properly. this option is usually useful when debugging the VLD itself.

----------------------------------------------------------
Slowdebuggerdump

If this parameter is allowed, the VLD will write the report to the output window of the debugger more slowly than normal. this parameter is used to ensure compatibility with earlier versions of vs. If you write content too quickly to it (the output window), information will be lost. if you notice that some information disappears from the report, try to open this parameter.

----------------------------------------------------------
Stackbeanmethod

You can select this parameter to migrate to the stack to obtain the requested memory call stack. the default "fast" method may not successfully track all stacks every time. in this case, the "safe" method may provide a more reliable method, but the disadvantage is that it is much slower than "fast" during debugging and may cause a significant reduction in performance. in most cases, setting this parameter to "fast" is correct.

If you really want to use the "safe" method, and notice the obvious performance decline. you may want to use the maxtraceframes parameter to limit the number of frames. this greatly reduces the amount of time spent on tracking stacks.

----------------------------------------------------------
Startdisabled

Set this option to "yes" to disable memory detection at the beginning. in this way, you can selectively allow memory detection during the runtime without re-building the program. however, this parameter should be used with caution. Any memory leakage may occur during the disabled or permitted detection.

----------------------------------------------------------
Traceinternalframes
This parameter indicates whether all call stack frames (including internal frames in the heap) are tracked. on the call stack, there are many frames used to determine the cause of leakage. They are the internal frames of VLD, C/C ++, and Win32 heap APIs. generally, these frames are skipped during stack tracing, which reduces the time spent tracking, collecting, and storing data. the tracing stack contains all frames. All methods include VLD code, but it is only useful for debugging VLD.
 
 
Control VLD at runtime
With the default configuration, VLD memory detection will run throughout the entire stage of your program running. in some cases, you may like to disable memory detection in some code segments. VLD provides simple APIs to control the memory detection status during runtime. to use these APIs, the required source file contains VLD. h.

Vlddisable

This function prohibits Memory leakage detection. After calling this function, the memory leakage detection will be disabled until vldenable is called explicitly.
Void vlddisable (void );

Parameters:

Parameters are not required for this function.

Return Value:

None (always successful ).

Note:
This function controls memory leakage detection based on each thread. in other words, calling this function only disables Memory leakage detection for the threads that call this function. other threads of the same process are still allowed. this isolates programmers from having to synchronize multiple threads to allow or disable VLD. note: this also means that to disable all VLD instances within the process range, you need to call this function in each thread.

Vldenable
This function allows memory leakage detection if it has been disabled before. After calling this function, VLD will remain in the allowed Detection Status and the vlddisable () is explicitly called ().
Void vldenable (void );

Parameters:

No Parameters
Return Value:

None (always successful ).

Note:
Similar to vlddisable, this function is based on the thread range.