123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660 |
- <?xml version="1.0" encoding="iso-8859-1"?>
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
- <head>
- <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
- <style title="Visual Leak Detector" type="text/css" media="screen,print">
- body {
- margin: 0;
- font-family: verdana, sans-serif;
- }
- #masthead {
- border-width: 0 0 1px 0;
- border-style: solid;
- border-color: #808080;
- background-color: #3569cc;
- }
- #content {
- margin: 1em 1em 1em 1em;
- font-size: 10pt;
- }
- #toc {
- float: right;
- background-color: #ffeda5;
- }
- h1 {
- margin: 0 0 0 0;
- padding: 0.5em 1em 0 1em;
- text-align: right;
- font-size: 24pt;
- font-family: arial, sans-serif;
- color: #ffffff;
- }
- h2 {
- margin-top: 0;
- border-width: 2px;
- border-style: solid;
- border-color: #3569cc;
- padding-left: 1em;
- font-size: 16pt;
- font-family: trebuchet ms, sans-serif;
- letter-spacing: -1pt;
- background-color: #6599fc;
- }
- h3 {
- font-size: 11pt;
- }
- li {
- margin-bottom: 1em;
- }
- #toc h2 {
- margin: 0;
- border-width: 2px 2px 2px 0;
- border-style: solid;
- border-color: #6599fc;
- text-align: center;
- color: #ffffff;
- background-color: #3569cc;
- }
- #toc ul {
- margin-left: 0;
- padding: 0;
- list-style: none;
- }
- #toc li {
- margin: 1em;
- }
- a {
- color: #0000ff;
- text-decoration:none;
- }
- a:hover {
- text-decoration: underline;
- }
- a:visited {
- color: #0000ff;
- }
- .preprocessor {
- font-size: 10pt;
- font-weight: bold;
- }
- .api {
- font-size: 12pt;
- font-weight: bold;
- }
- .code {
- font-family: courier new, monospace;
- background-color: #e0e0e0;
- }
- .filename, .operator, .function {
- font-style: italic;
- }
- .note {
- margin-left: 2em;
- }
- #slogan {
- margin-bottom: 0;
- padding: 0 1em 1em 1em;
- border-width: 0 0 1px 0;
- border-style: solid;
- border-color: #404040;
- text-align: right;
- font-size: larger;
- font-style: italic;
- color: #6599fc;
- }
- #copyright {
- text-align: right;
- font-family: georgia, serif;
- color: #808080;
- }
- #compliance {
- text-align: right;
- }
- #compliance img {
- border: 0;
- }
- </style>
- <title>Visual Leak Detector</title>
- </head>
- <body>
- <div id="masthead">
- <h1>Visual Leak Detector 1.0</h1>
- <p id="slogan">Enhanced Memory Leak Detection for Visual C++</p>
- </div> <!-- #masthead -->
- <div id="content">
- <div id="toc">
- <h2>Table of Contents</h2>
- <ul>
- <li><a href="#intro">Introduction</a></li>
- <li><a href="#use">Using Visual Leak Detector</a></li>
- <li><a href="#configure">Configuration Options</a></li>
- <li><a href="#control">Controlling Leak Detection at Runtime</a></li>
- <li><a href="#dlls">Detecting Leaks in DLLs</a></li>
- <li><a href="#build">Building Visual Leak Detector from Source</a></li>
- <li><a href="#x64">Windows x64 Support</a></li>
- <li><a href="#faq">Frequently Asked Questions</a></li>
- <li><a href="#restrictions">Known Restrictions</a></li>
- <li><a href="#license">License</a></li>
- <li><a href="#contact">Contacting the Author</a></li>
- </ul>
- </div> <!-- #toc -->
- <h2 id="intro">Introduction</h2>
- <p>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:</p>
- <ul>
- <li>Provides a complete stack trace for each leaked block, including source file and line number information when
- available.</li>
- <li>Provides complete data dumps (in hex and ASCII) of leaked blocks.</li>
- <li>Customizable level of detail in the memory leak report.</li>
- </ul>
- <p>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.
- Here's some key advantages that Visual Leak Detector has over many other free alternatives:</p>
- <ul>
- <li>Visual Leak Detector is cleanly packaged as an easy-to-use library. You don't need to compile its source code to
- use it. And you only need to make minor additions to your own source code to integrate it with your program.</li>
- <li>In addition to providing stack traces with source files, line numbers, and function names, Visual Leak Detector
- also provides data dumps.</li>
- <li>It works with both C++ and C programs (compatible with both
- <span class="operator">new</span>/<span class="operator">delete</span> and
- <span class="function">malloc</span>/<span class="function">free</span>).</li>
- <li>The full source code to the library is included and it is well documented, so it is easy to customize it to suit your
- needs.</li>
- </ul>
- <p>Visual Leak Detector is <a href="#license">licensed</a> free of charge as a service to the Windows developer community. If you
- find it to be useful and would like to just say "Thanks!", or you think it stinks and would like to say "This thing sucks!",
- please feel free to <a href="mailto:dmoulding@gmail.com">drop me a note</a>. Or, if you'd prefer, you can
- <a href="#contact">contribute a small donation</a>. Both are very appreciated.</p>
- <h2 id="use">Using Visual Leak Detector</h2>
- <p>This section briefly describes the basics of using Visual Leak Detector (VLD). If your project contains DLLs that you'd
- like to also check for memory leaks, please see <a href="#dlls">Detecting Leaks in DLLs</a>.</p>
- <p>To use VLD with your project, follow these simple steps:</p>
- <ol>
- <li>Copy the VLD library (<span class="filename">*.lib</span>) files to your Visual C++ installation's "lib"
- subdirectory.</li>
- <li>Copy the VLD header files (<span class="filename">vld.h</span> and <span class="filename">vldapi.h</span>) to your
- Visual C++ installation's "include" subdirectory.</li>
- <li>In the source file containing your program's main entry point, include the <span class="filename">vld.h</span> header file.
- It's best, but not absolutely required, to include this header before any other header files, except for
- <span class="filename">stdafx.h</span>. If the source file includes <span class="filename">stdafx.h</span>, then
- <span class="filename">vld.h</span> should be included after it.</li>
- <li>If you are running Windows 2000 or earlier, then you will need to copy <span class="filename">dbghelp.dll</span> to the
- directory where the executable being debugged resides.</li>
- <li>Build the debug version of your project.</li>
- </ol>
- <p>VLD will detect memory leaks in your program whenever you run the debug version under the Visual C++ debugger. A report of
- all the memory leaks detected will be displayed in the debugger's output window when your program exits. Double-clicking on a
- source file's line number in the memory leak report will take you to that file and line in the editor window, allowing easy
- navigation of the code path leading up to the allocation that resulted in a memory leak.</p>
- <p class="note"><strong>Note:</strong> When you build release versions of your program, VLD will not be linked into the executable.
- So it is safe to leave <span class="filename">vld.h</span> included in your source files when doing release builds. Doing so will
- not result in any performance degradation or any other undesirable overhead.</p>
- <h2 id="configure">Configuration Options</h2>
- <p>There are a few optional preprocessor macros that you can define to control certain aspects of VLD's operation, including the
- level of detail provided in the memory leak report:</p>
- <dl>
- <dt class="preprocessor">VLD_AGGREGATE_DUPLICATES</dt>
- <dd>
- <p>Normally, VLD displays each individual leaked block in detail. Defining this macro will make VLD aggregate all leaks that
- share the same size and call stack under a single entry in the memory leak report. Only the first leaked block will be
- reported in detail. No other identical leaks will be displayed. Instead, a tally showing the total number of leaks matching
- that size and call stack will be shown. This can be useful if there are only a few sources of leaks, but those few sources
- are repeatedly leaking a very large number of memory blocks.</p>
- </dd>
- <dt class="preprocessor">VLD_MAX_TRACE_FRAMES</dt>
- <dd>
- <p>By default, VLD will trace the call stack for each allocated block as far back as possible. Each frame traced adds
- additional overhead (in both CPU time and memory usage) to your debug executable. If you'd like to limit this overhead, you
- can define this macro to an integer value. The stack trace will stop when it has traced this number of frames. The frame
- count includes the "useless" frames which, by default, are not displayed in the debugger's output window (see
- VLD_SHOW_USELESS_FRAMES below). Usually, there will be about five or six "useless" frames at the beginning of the call
- stack. Keep this in mind when using this macro, or you may not see the number of frames you expect.</p>
- </dd>
- <dt class="preprocessor">VLD_MAX_DATA_DUMP</dt>
- <dd>
- <p>Define this macro to an integer value to limit the amount of data displayed in memory block data dumps. When this number of
- bytes of data has been dumped, the dump will stop. This can be useful if any of the leaked blocks are very large and the
- debugger's output window becomes too cluttered. You can define this macro to 0 (zero) if you want to suppress data dumps
- altogether.</p>
- </dd>
- <dt class="preprocessor">VLD_SELF_TEST</dt>
- <dd>
- <p>VLD has the ability to check itself for memory leaks. This feature is always active. Every time you run VLD, in addition
- to checking your own program for memory leaks, it is also checking itself for leaks. Defining this macro forces VLD to
- intentionally leak a small amount of memory: a 21-byte block filled with the text "Memory Leak Self-Test". This provides
- a way to test VLD's ability to check itself for memory leaks and verify that this capability is working correctly.
- This macro is usually only useful for debugging VLD itself.</p>
- </dd>
- <dt class="preprocessor">VLD_SHOW_USELESS_FRAMES</dt>
- <dd>
- <p>By default, only "useful" frames are printed in the call stacks. Frames that are internal to the heap or VLD are not shown.
- Define this to force all frames of the call stacks to be printed. This macro is usually only useful for debugging VLD
- itself.</p>
- </dd>
- <dt class="preprocessor">VLD_START_DISABLED</dt>
- <dd>
- <p>Define this macro to disable memory leak detection initially. This can be useful if you need to be able to selectively
- enable memory leak detection from runtime, without needing to rebuild the executable; however, this macro should be used
- with caution. Any memory leaks that may occur before memory leak detection is enabled at runtime will go undetected. For
- example, if the constructor of some global variable allocates memory before execution reaches a subsequent call to
- <span class="function">VLDEnable</span>, then VLD will not be able to detect if the memory allocated by the global
- variable is never freed. Refer to the following section on <a href="#control">controlling leak detection at runtime</a>
- for details on using the runtime APIs which can be useful in conjunction with this preprocessor macro.</p>
- </dd>
- </dl>
- <h2 id="control">Controlling Leak Detection at Runtime</h2>
- <p>Using the default configuration, VLD's memory leak detection will be enabled during the entire run of your program. In certain
- scenarios it may be desirable to selectively disable memory leak detection in certain segments of your code. VLD provides simple
- APIs for controlling the state of memory leak detection at runtime. To access these APIs, include
- <span class="filename">vldapi.h</span> in your source file. These APIs are described here in detail:</p>
- <dl>
- <dt class="api">VLDDisable</dt>
- <dd>
- <p>This function disables memory leak detection. After calling this function, memory leak detection will remain disabled
- until it is explicitly re-enabled via a call to VLDEnable.</p>
- <p class="code">void VLDDisable (void);</p>
- <h3>Arguments:</h3>
- <p>This function accepts no arguments.</p>
- <h3>Return Value:</h3>
- <p>None (this function always succeeds).</p>
- <h3>Notes:</h3>
- <p>This function controls memory leak detection on a per-thread basis. In other words, calling this function disables
- memory leak detection for only the thread that called the function. Memory leak detection will remain enabled for any
- other threads in the same process. This insulates the programmer from having to synchronize multiple threads that
- disable and enable memory leak detection. However, note also that this means that in order to disable memory leak
- detection process-wide, this function must be called from every thread in the process.</p>
- </dd>
- <dt class="api">VLDEnable</dt>
- <dd>
- <p>This function enables memory leak detection if it was previously disabled. After calling this function, memory leak
- detection will remain enabled unless it is explicitly disabled again via a call to VLDDisable().</p>
- <p class="code">void VLDEnable (void);</p>
- <h3>Arguments:</h3>
- <p>This function accepts no arguments.</p>
- <h3>Return Value:</h3>
- <p>None (this function always succeeds).</p>
- <h3>Notes:</h3>
- <p>This function controls memory leak detection on a per-thread basis. See the remarks for
- <span class="function">VLDDisable</span> regarding multithreading and memory leak detection for details. Those same
- concepts also apply to this function.</p>
- </dd>
- </dl>
- <h2 id="dlls">Detecting Leaks in DLLs</h2>
- <p>VLD is capable of detecting memory leaks in DLLs. But DLLs can present special situations that need to be carefully considered to
- ensure that VLD can properly do its job. When using DLLs, you will have more than one module. Each DLL is a module and the main
- executable is also a module. VLD should be linked with only one module per process. So the question is: which module should VLD
- be linked with? The answer will depend on whether your DLLs are load-time linked or run-time linked. <em>The general rule of
- thumb is that VLD should always be linked with the module that is initialized first.</em></p>
- <h3>Load-Time Dynamic Linking</h3>
- <p>This is probably the most commonly used way to link with DLLs. If your program doesn't use
- <span class="function">LoadLibrary</span> to load your DLL, then this is the type of dynamic linking your program uses. With this
- form of linking, the DLL is initialized before the program's main executable. Therefore, the DLL is the first module to be
- initialized and VLD should be linked with the DLL. Include <span class="filename">vld.h</span> in the main source file for the
- DLL.</p>
- <p>Of course, there will most likely be several system DLLs that are loaded before any of your own DLLs. You don't need to worry
- about linking VLD with those DLLs, because those DLLs are not being checked for memory leaks. Only your own DLLs will be checked
- for leaks so VLD only needs to be linked with the first DLL <em>of your own</em> which is loaded first.</p>
- <p>As was mentioned earlier, you should only link VLD with <em>one</em> module. In almost all situations, linking VLD with just one
- module that will be loaded in a given process will enable VLD to detect memory leaks in all other modules loaded in the same
- process. This means that if your program links with several load-time DLLs, you only need to link with one of them -- the one
- that is loaded first. This rule also applies if a mix of load-time linked and run-time linked DLLs are used.</p>
- <p>One obvious question all of this gives rise to is: which DLL will load first and how will you know? That is a difficult question
- to answer. Because DLL dependencies can be circular, there is no guaranteed way to determine DLL load order. It is entirely up to
- the DLL loader and any seemingly innocuous change can alter the order that DLLs are loaded. But in general, DLLs that are
- dependencies of many other DLLs will probably be loaded sooner rather than later. If you just want to know which DLL is loaded
- first with your project, run it under the Visual C++ debugger. It will display a list of all the DLLs that are loaded and in
- which order. But be aware that changes to the project might unexpectedly change the DLL load order.</p>
- <h3>Runtime Dynamic Linking</h3>
- <p>You know you're using this type of dynamic linking if your program calls <span class="function">LoadLibrary</span> to load your
- DLL. With this type of dynamic linking, the DLL is not initialized until <span class="function">LoadLibrary</span> is called.
- Therefore, if all of your DLLs are runtime linked, then the main executable is the first module to be initialized and VLD should
- be linked with the main executable. Include <span class="filename">vld.h</span> in the main source file for the main
- executable.</p>
- <h3>Using DLLs and the Static C Runtime Libraries</h3>
- <p>This refers to using DLLs in conjunction with the /ML or /MT compiler options. If you do this, then there are some things you
- should be aware of. This creates more than one copy of the CRT in the same process. There are many things that you cannot do
- across CRT boundaries. For example, you can't allocate memory in one CRT instance and free it in another. This isolation of CRT
- instances has important ramifications for VLD. VLD can normally only monitor memory allocations from a single CRT instance. If
- there are two CRTs in the same process then a single instance of VLD can only detect memory leaks in one of the CRT instances
- (even though both exist in the same process). If you want to be able to detect memory leaks in two instances of the CRT, then
- you'll need two instances of VLD -- one for each CRT instance. To do this, link VLD with both the main executable (where one of
- the CRT instances resides) and one of the DLLs (usually all DLLs will share one instance of the CRT). The same rules from above
- apply when deciding which DLL to link with. The downside to this is that each instance of VLD will generate its own memory leak
- report.</p>
- <h2 id="build">Building Visual Leak Detector from Source</h2>
- <p>Because Visual Leak Detector is open source, the libraries can be built from source if you want to tweak them to your
- liking. The hardest part about building the VLD libraries from source is getting your build environment correctly set up. But if
- you follow these instructions carefully, the process should be fairly painless.</p>
- <ol>
- <li>VLD depends on the Debug Help library header file, <span class="filename">dbghelp.h</span>. This header file won't exist
- unless you have a recent Platform SDK installed. If you don't see <span class="filename">dbghelp.h</span> in your
- Platform SDK's "include" directory, then you probably need to
- <a href="http://www.microsoft.com/msdownload/platformsdk/sdkupdate/">update your Platform SDK</a>.</li>
- <li>Visual C++ will need to be made aware of where it can find the Debug Help library header file. If you have not done so
- already, add the "include" subdirectory from the Platform SDK installation directory to the include search path in
- Visual C++:
- <ul>
- <li><strong>Visual C++ 7</strong>: Go to Project Properties -> C/C++ -> General -> Additional Include Directories and
- add the "include" subdirectory from the Platform SDK. Make sure it's at the top of the list.</li>
- <li><strong>Visual C++ 6</strong>: Go to Tools -> Options -> Directories. Select "Include files" from the "Show
- Directories For" drop-down menu. Add the "include" subdirectory from the Platform SDK. Make sure it's at the top of
- the list.</li>
- </ul>
- </li>
- <li>VLD also depends on two other header files (<span class="filename">dbgint.h</span> and
- <span class="filename">mtdll.h</span>) that will only be installed if you elected to install the CRT source files when you
- installed Visual C++. If you didn't install the CRT sources, you'll need to re-run the Visual C++ installer and
- install them. If you are not sure whether you installed the CRT sources when you installed Visual C++, check to see if
- <span class="filename">dbgint.h</span> and <span class="filename">mtdll.h</span> exist in the "CRT\src" subdirectory of your
- Visual C++ installation directory. If those files are missing, or you don't have a "CRT\src" directory, then chances
- are you need to re-install Visual C++ with the CRT sources selected.</li>
- <li>Make sure that your Visual C++ installation's "CRT\src" subdirectory is in the include search path. Refer to step 2 for
- instructions on how to add directories to the include search path. The "CRT\src" subdirectory should go after the default
- include directory. To summarize, your include search path should look like this:
- <ul>
- <li>C:\Program Files\Microsoft Platform SDK\Include</li>
- <li>C:\Program Files\Microsoft Visual Studio\VCx\Include</li>
- <li>C:\Program Files\Microsoft Visual Studio\CRT\src</li>
- </ul>
- <p>In the above example, "VCx" would be "VC7" for Visual Studio .NET or "VC98" for Visual Studio 6.0. Also,
- the name of your Platform SDK directory might be different from the example depending on which version of the
- Platform SDK you have installed.</p>
- </li>
- </ol>
- <p>Once you've completed all of the above steps, your build environment should be ready. To build VLD, just open the
- <span class="filename">vld.dsp</span> project and do a batch build to build all six of the configurations:</p>
- <ul>
- <li>The three debug configurations are for building versions of the library that have debugging information so that VLD itself
- can be conveniently debugged.</li>
- <li>The three release configurations build the library for use in debugging other programs.</li>
- <li>There are three configurations each: one for each method of linking with the C runtime library (single-threaded static,
- multithreaded static, and multithreaded DLL). When linking the VLD library against a program, the
- <span class="filename">vld.h</span> header file detects how the program is linking to the C runtime library and selects the
- appropriate VLD library from the three possible choices.</li>
- </ul>
- <p class="note"><strong>Note:</strong> The "release" builds of the VLD libraries are not like typical release builds. Despite the
- "release" name, they are actually meant to be linked only to debug builds of your own programs. When doing release builds of your
- programs, VLD will not be linked to them at all. In the context of VLD, "release" simply means the versions that are optimized
- and have the symbols stripped from them (to make the libraries smaller). They are the versions of the libraries that are included
- in the release of VLD itself (hence the "release" name). So when you are building the release libraries, you're really building
- the same libraries that are included in the main VLD distribution. The "debug" builds of VLD are strictly for debugging VLD
- itself (e.g. if you want to modify it or if you need to fix a bug in it).</p>
- <h2 id="x64">Windows x64 Support</h2>
- <p>The VLD source code has been modified to add support for x64-based 64-bit Windows. However, the binaries contained in the
- distributed versions of VLD are 32-bit only. To take advantage of the 64-bit support, you'll need to build 64-bit versions of the
- libraries from source. To build the 64-bit versions, follow the instructions for <a href="#build">building VLD from source</a>.
- So long as they are built using a x64-compatible compiler in 64-bit mode, the resulting libraries will be 64-bit libraries.</p>
- <p class="note"><strong>Note:</strong> I have not personally tested the 64-bit extensions so they are not absolutely guaranteed to
- work out-of-the-box. There may be a few lingering 64-bit compiler errors that still need to be worked out. If you need 64-bit
- support and run into problems trying to build the source in 64-bit mode, please
- <a href="mailto:dmoulding@gmail.com">let me know</a>. I'll be glad to assist in getting the 64-bit code working properly.</p>
- <h2 id="faq">Frequently Asked Questions</h2>
- <dl>
- <dt>When running my program with VLD linked to it I get an error message saying, "the procedure entry point SymFromAddr could
- not be located in the dynamic link library dbghelp.dll".</dt>
- <dd>
- <p>This typically only happens on Windows 2000. It will happen if the Debug Help Library is out-of-date. Copy the included
- version of <span class="filename">dbghelp.dll</span> (version 6.3) to the directory where the executable you are
- debugging resides. If <span class="filename">dbghelp.dll</span> is missing for some reason, you can get it by installing
- <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx">Debugging Tools for Windows</a>. I recommend
- installing version 6.3.</p>
- </dd>
- <dt>When building VLD from source, I get the fatal error "C1189: #error : ERROR: Use of C runtime library internal header
- file." in either the file stdio.h or in the file assert.h (or possibly in some other standard header file).</dt>
- <dd>
- <p>Visual C++ is including the wrong copies of the standard headers. Be sure that the "CRT\src" subdirectory of your
- Visual C++ installation directory is listed <em>after</em> the "include" subdirectory in Visual C++'s include
- search path.</p>
- </dd>
- <dt>When building VLD from source, I get Compile Error C1083: "Cannot open include file: 'dbgint.h': No such file or
- directory"</dt>
- <dd>
- <p>This will happen if the CRT source files are not installed. These are an optional part of the installation when you first
- install Visual C++. Re-run the Visual C++ installation, if needed, to install them. If the CRT sources are
- already installed, make sure the "CRT\src" subdirectory of the Visual C++ installation directory is in
- Visual C++'s include search path.</p>
- </dd>
- <dt>Is Visual Leak Detector compatible with platforms other than Microsoft Windows?</dt>
- <dd>
- <p>No. It is designed specifically for use with Visual C++, and it depends on heap debugging functions found only in
- Microsoft's C runtime library. It's called <em>Visual</em> Leak Detector for a reason.</p>
- </dd>
- </dl>
- <h2 id="restrictions">Known Restrictions</h2>
- <p>Known restrictions in the current version of VLD, as of the time of this writing, include:</p>
- <ul>
- <li>VLD does not detect COM leaks, out-of-process resource leaks, or any other types of memory leaks that are not associated
- with the CRT heap. In simpler terms, VLD only detects memory leaks that are the result of calls to
- <span class="function">new</span> or <span class="function">malloc</span>.</li>
- <li>VLD is not compatible with version 6.5 of the Debug Help library (<span class="filename">dbghelp.dll</span>). The
- recommended version of <span class="filename">dbghelp.dll</span> to use with VLD is 6.3. Version 6.3 is included in the VLD
- distribution.</li>
- <li>The pre-compiled libraries included in the VLD distribution may not be compatible with Visual Studio 2005. If you
- need to use VLD with Visual Studio 2005, <a href="#build">building VLD from source</a> in
- Visual Studio 2005 should create compatible libraries.</li>
- </ul>
- <h2 id="license">License</h2>
- <p>Visual Leak Detector is distributed under the terms of the <a href="http://www.gnu.org/copyleft/lesser.html">GNU Lesser
- General Public License</a>. See the <span class="filename"><a href="COPYING.txt">COPYING.txt</a></span> file for details.</p>
- <p>The Debug Help Library (<span class="filename">dbghelp.dll</span>) distributed with this software is not part of
- Visual Leak Detector and is not covered under the terms of the GNU Lesser General Public License. It is a separately
- copyrighted work of Microsoft Corporation. Microsoft reserves all its rights to its copyright in the Debug Help Library. Neither
- your use of the Visual Leak Detector software, nor your license under the GNU Lesser General Public license grant you
- any rights to use the Debug Help Library in <strong>ANY WAY</strong> (for example, redistributing it) that would infringe upon
- Microsoft Corporation's copyright in the Debug Help Library.</p>
- <h3>NO WARRANTY</h3>
- <p>BECAUSE VISUAL LEAK DETECTOR ("THE SOFTWARE") IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT
- PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE
- SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS
- WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.</p>
- <p>IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
- MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE LICENSING TERMS SET FORTH ABOVE, BE LIABLE TO YOU FOR DAMAGES,
- INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE
- (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
- FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
- POSSIBILITY OF SUCH DAMAGES.</p>
- <h2 id="contact">Contacting the Author</h2>
- <p>Please forward any bug reports, questions, comments or suggestions to me at
- <a href="mailto:dmoulding@gmail.com">dmoulding@gmail.com.</a></p>
- <p>Donations to help support ongoing development of Visual Leak Detector are very appreciated!</p>
- <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
- <div>
- <input type="hidden" name="cmd" value="_s-xclick" />
- <input type="image" src="https://www.paypal.com/en_US/i/btn/x-click-but21.gif" name="submit" alt="Make payments with PayPal - it's fast, free and secure!" />
- <input type="hidden" name="encrypted" value="-----BEGIN PKCS7-----MIIHJwYJKoZIhvcNAQcEoIIHGDCCBxQCAQExggEwMIIBLAIBADCBlDCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKEwtQYXlQYWwgSW5jLjETMBEGA1UECxQKbGl2ZV9jZXJ0czERMA8GA1UEAxQIbGl2ZV9hcGkxHDAaBgkqhkiG9w0BCQEWDXJlQHBheXBhbC5jb20CAQAwDQYJKoZIhvcNAQEBBQAEgYB96070OV1fBDnfqkGvVtR2bQf+WKQk1DquH9rhxL3QPke1DxmckKvbKQwjqYRjZN+FbaFky71Lz75RsdeJHKcxgcJWw6cMYOI2xrmsa4Vjp00iOPjKGpMBE7roPqnnZT7l36wBBVk7Hbnm8A3MHsqTQXN9/S/rbngN57tANCbsRTELMAkGBSsOAwIaBQAwgaQGCSqGSIb3DQEHATAUBggqhkiG9w0DBwQIfRWj6EIw0C+AgYCtBQ3JuPXxq/j/RpOCteLqJqyePyFExF3ic44Doj4py33hRo9EqJrSUTbigQVT2eHkwQWS9Exs8L9aeBQQahsZNbUCyLgqPvXOOG/Zk+5Xj/2m2oBZ5AMW8rdPVCYJ7NhAc92aiU2yObd/I8n4mLGDRf768HhASKwe/LGmZiH2bKCCA4cwggODMIIC7KADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxFDASBgNVBAoTC1BheVBhbCBJbmMuMRMwEQYDVQQLFApsaXZlX2NlcnRzMREwDwYDVQQDFAhsaXZlX2FwaTEcMBoGCSqGSIb3DQEJARYNcmVAcGF5cGFsLmNvbTAeFw0wNDAyMTMxMDEzMTVaFw0zNTAyMTMxMDEzMTVaMIGOMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxFDASBgNVBAoTC1BheVBhbCBJbmMuMRMwEQYDVQQLFApsaXZlX2NlcnRzMREwDwYDVQQDFAhsaXZlX2FwaTEcMBoGCSqGSIb3DQEJARYNcmVAcGF5cGFsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwUdO3fxEzEtcnI7ZKZL412XvZPugoni7i7D7prCe0AtaHTc97CYgm7NsAtJyxNLixmhLV8pyIEaiHXWAh8fPKW+R017+EmXrr9EaquPmsVvTywAAE1PMNOKqo2kl4Gxiz9zZqIajOm1fZGWcGS0f5JQ2kBqNbvbg2/Za+GJ/qwUCAwEAAaOB7jCB6zAdBgNVHQ4EFgQUlp98u8ZvF71ZP1LXChvsENZklGswgbsGA1UdIwSBszCBsIAUlp98u8ZvF71ZP1LXChvsENZklGuhgZSkgZEwgY4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEUMBIGA1UEChMLUGF5UGFsIEluYy4xEzARBgNVBAsUCmxpdmVfY2VydHMxETAPBgNVBAMUCGxpdmVfYXBpMRwwGgYJKoZIhvcNAQkBFg1yZUBwYXlwYWwuY29tggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAgV86VpqAWuXvX6Oro4qJ1tYVIT5DgWpE692Ag422H7yRIr/9j/iKG4Thia/Oflx4TdL+IFJBAyPK9v6zZNZtBgPBynXb048hsP16l2vi0k5Q2JKiPDsEfBhGI+HnxLXEaUWAcVfCsQFvd2A1sxRr67ip5y2wwBelUecP3AjJ+YcxggGaMIIBlgIBATCBlDCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQwEgYDVQQKEwtQYXlQYWwgSW5jLjETMBEGA1UECxQKbGl2ZV9jZXJ0czERMA8GA1UEAxQIbGl2ZV9hcGkxHDAaBgkqhkiG9w0BCQEWDXJlQHBheXBhbC5jb20CAQAwCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgwMTE5NDQ0NlowIwYJKoZIhvcNAQkEMRYEFKLDwHJFsU6L329159saLBrfszYcMA0GCSqGSIb3DQEBAQUABIGAe4Mjshnc1RvJU9zF6nL8zPJ+nHO2ct1CbS1WFkQMWvh2NTwlIVSZFWSLJQZ32kNoyseoxUvE587qdBKyMOATXjchDeMr1y815+GWE6Ffqw3rWw/ytfVEtEJd4yUUq0gHqFACul4nWM5zP5A3zkLZEVN3gAmX1eLbMIcSCKuVafM=-----END PKCS7-----" />
- </div>
- </form>
- <p id="compliance">
- <a href="http://validator.w3.org/check?uri=referer"><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" /></a>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img id="valid-css" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!" /></a>
- </p>
- <p id="copyright">Copyright © 2005 Dan Moulding</p>
- </div> <!-- #content -->
- </body>
- </html>
|