1 <?xml version="1.0" encoding="iso-8859-1"?>
\r
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
\r
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
\r
6 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
\r
8 <style title="Visual Leak Detector" type="text/css" media="screen,print">
\r
11 font-family: verdana, sans-serif;
\r
15 border-width: 0 0 1px 0;
\r
16 border-style: solid;
\r
17 border-color: #808080;
\r
19 background-color: #3569cc;
\r
23 margin: 1em 1em 1em 1em;
\r
30 background-color: #ffeda5;
\r
35 padding: 0.5em 1em 0 1em;
\r
38 font-family: arial, sans-serif;
\r
44 border-style: solid;
\r
45 border-color: #3569cc;
\r
48 font-family: "trebuchet ms", sans-serif;
\r
49 letter-spacing: -1pt;
\r
51 background-color: #6599fc;
\r
64 border-width: 2px 2px 2px 0;
\r
65 border-style: solid;
\r
66 border-color: #6599fc;
\r
69 background-color: #3569cc;
\r
84 background-color: inherit;
\r
85 text-decoration:none;
\r
89 text-decoration: underline;
\r
94 background-color: inherit;
\r
103 font-family: "courier new", monospace;
\r
105 background-color: #e0e0e0;
\r
109 font-style: italic;
\r
113 font-style: italic;
\r
121 font-style: italic;
\r
131 border-style: dashed;
\r
132 border-color: #000000;
\r
134 background-color: #ffeda5;
\r
138 ul.vcsearchpath li {
\r
144 padding: 0 1em 1em 1em;
\r
145 border-width: 0 0 1px 0;
\r
146 border-style: solid;
\r
147 border-color: #404040;
\r
150 font-style: italic;
\r
152 background-color: inherit;
\r
157 font-family: georgia, serif;
\r
159 background-color: inherit;
\r
171 font-style: italic;
\r
175 <title>Visual Leak Detector (Beta)</title>
\r
184 <div id="masthead">
\r
186 <h1>Visual Leak Detector 1.9f (Beta)</h1>
\r
188 <p id="slogan">Enhanced Memory Leak Detection for Visual C++</p>
\r
190 </div> <!-- #masthead -->
\r
199 <h2>Table of Contents</h2>
\r
202 <li><a href="#intro">Introduction</a></li>
\r
204 <li><a href="#use">Using Visual Leak Detector</a></li>
\r
206 <li><a href="#configure">Configuration Options</a></li>
\r
208 <li><a href="#control">Controlling Leak Detection at Runtime</a></li>
\r
210 <li><a href="#build">Building Visual Leak Detector from Source</a></li>
\r
212 <li><a href="#x64">Windows x64 Support</a></li>
\r
214 <li><a href="#faq">Frequently Asked Questions</a></li>
\r
216 <li><a href="#restrictions">Known Restrictions</a></li>
\r
218 <li><a href="#license">License</a></li>
\r
220 <li><a href="#contact">Contacting the Author</a></li>
\r
223 </div> <!-- #toc -->
\r
228 <h2 id="intro">Introduction</h2>
\r
230 <p>Visual C++ provides built-in memory leak detection, but its capabilities are minimal at best. This memory leak
\r
231 detector was created as a free alternative to the built-in memory leak detector provided with Visual C++. Here
\r
232 are some of Visual Leak Detector's features, none of which exist in the built-in detector:</p>
\r
235 <li>Provides a complete stack trace for each leaked block, including source file and line number information when
\r
238 <li>Detects most, if not all, types of in-process memory leaks including COM-based leaks, and pure Win32 heap-based
\r
241 <li>Selected modules (DLLs or even the main EXE) can be excluded from leak detection.</li>
\r
243 <li>Provides complete data dumps (in hex and ASCII) of leaked blocks.</li>
\r
245 <li>Customizable memory leak report: can be saved to a file or sent to the debugger and can include a variable level
\r
249 <p>Other after-market leak detectors for Visual C++ are already available. But most of the really popular ones,
\r
250 like Purify and BoundsChecker, are very expensive. A few free alternatives exist, but they're often too intrusive,
\r
251 restrictive, or unreliable. Visual Leak Detector is currently the only freely available memory leak
\r
252 detector for Visual C++ that provides all of the above professional-level features packaged neatly in an easy-to-use
\r
255 <p>Visual Leak Detector is <a href="#license">licensed</a> free of charge as a service to the Windows developer
\r
256 community. If you find it to be useful and would like to just say "Thanks!", or you think it stinks and would like to
\r
257 say "This thing sucks!", please feel free to <a href="mailto:dmoulding@gmail.com">drop me a note</a>. Or, if you'd
\r
258 prefer, you can <a href="#contact">contribute a small donation</a>. Both are very appreciated.</p>
\r
263 <h2 id="use">Using Visual Leak Detector</h2>
\r
265 <p>This section briefly describes the basics of using Visual Leak Detector (VLD).</p>
\r
267 <p><strong>Important! :</strong> Before using VLD with any Visual C++ project, you must first add the Visual Leak
\r
268 Detector include and library directories to the Visual C++ include and library directory search paths:</p>
\r
271 <li><strong>Visual C++ 8</strong>: Go to Tools -> Options -> Projects and Solutions -> VC++ Directories.
\r
272 Select "Include files" from the "Show Directories For" drop-down menu. Add the
\r
273 <span class="filename">include</span> subdirectory from the Visual Leak Detector installation directory. Move it
\r
274 to the bottom of the list. Then select "Library files" from the drop-down menu and add the
\r
275 <span class="filename">lib</span> subdirectory from the Visual Leak Detector installation directory. Again, move
\r
276 it to the bottom of the list.</li>
\r
278 <li><strong>Visual C++ 7</strong>: Go to Project Properties -> C/C++ -> General -> Additional Include
\r
279 Directories and add the <span class="filename">include</span> subdirectory from the Visual Leak Detector
\r
280 installation directory. Move it to the bottom of the list. Then select Additional Library Directories and add
\r
281 the <span class="filename">lib</span> subdirectory from the Visual Leak Detector installation directory. Again,
\r
282 move it to the bottom of the list.</li>
\r
284 <li><strong>Visual C++ 6</strong>: Go to Tools -> Options -> Directories. Select "Include files" from
\r
285 the "Show Directories For" drop-down menu. Add the <span class="filename">include</span> subdirectory
\r
286 from the Visual Leak Detector installation directory. Move it to the bottom of the list. Then select "Library
\r
287 files" from the drop-down menu and add the <span class="filename">lib</span> subdirectory from the Visual Leak
\r
288 Detector installation directory. Again, move it to the bottom of the list.</li>
\r
291 <p>To use VLD with your project, follow these simple steps:</p>
\r
294 <li>In at least one C/C++ source file from your program, include the <span class="filename">vld.h</span> header
\r
295 file. It should not matter which file you add the include statement to. It also should not matter in what order
\r
296 the header is included in relation to other headers. The only exception is
\r
297 <span class="filename">stdafx.h</span> (or any other precompiled header). A precompiled header, such as
\r
298 <span class="filename">stdafx.h</span>, must always be the first header included in a source file, so
\r
299 <span class="filename">vld.h</span> must be included after any precompiled headers.</li>
\r
301 <li>If your program contains one or more DLLs that you would also like to check for memory leaks, then also include
\r
302 <span class="filename">vld.h</span> in at least one source file from each DLL to be included in leak
\r
305 <li>Build the debug version of your program.</li>
\r
308 <p class="note"><strong>Note:</strong> Unlike earlier (pre-1.9) versions of VLD, it is now acceptable to include
\r
309 <span class="filename">vld.h</span> in every source file, or to include it in a common header that is included by
\r
310 many or all source files. Only one copy of the VLD code will be loaded into the process, regardless of how many
\r
311 source files include <span class="filename">vld.h</span>.</p>
\r
313 <p>VLD will detect memory leaks in your program whenever you run the debug version. When you run the program under the
\r
314 Visual C++ debugger, a report of all the memory leaks detected will be displayed in the debugger's output window
\r
315 when your program exits (the report can optionally be saved to a file instead, see
\r
316 <span class="option">ReportFile</span> under <a href="#configure">Configuration Options</a>). Double-clicking on a
\r
317 source file's line number in the memory leak report will take you to that file and line in the editor window,
\r
318 allowing easy navigation of the code path leading up to the allocation that resulted in the memory leak.</p>
\r
320 <p class="note"><strong>Note:</strong> When you build release versions of your program, VLD will not be linked into the
\r
321 executable. So it is safe to leave <span class="filename">vld.h</span> included in your source files when doing
\r
322 release builds. Doing so will not result in any performance degradation or any other undesirable overhead.</p>
\r
327 <h2 id="configure">Configuration Options</h2>
\r
329 <p>There are a several configuration options that control specific aspects of VLD's operation. These configuration
\r
330 options are stored in the <span class="filename">vld.ini</span> configuration file. By default, the configuration
\r
331 file should be in the Visual Leak Detector installation directory. However, the configuration file can be copied to
\r
332 the program's working directory, in which case the configuration settings in that copy of
\r
333 <span class="filename">vld.ini</span> will apply only when debugging that one program.</p>
\r
336 <dt class="option">VLD</dt>
\r
338 <p>This option acts as a master on/off switch. By default, this option is set to "on". To <em>completely
\r
339 disable</em> Visual Leak Detector at runtime, set this option to "off". When VLD is turned off using this
\r
340 option, it will do nothing but print a message to the debugger indicating that it has been turned off.</p>
\r
343 <dt class="option">AggregateDuplicates</dt>
\r
345 <p>Normally, VLD displays each individual leaked block in detail. Setting this option to "yes" will make VLD
\r
346 aggregate all leaks that share the same size and call stack under a single entry in the memory leak report.
\r
347 Only the first leaked block will be reported in detail. No other identical leaks will be displayed. Instead,
\r
348 a tally showing the total number of leaks matching that size and call stack will be shown. This can be useful
\r
349 if there are only a few sources of leaks, but those few sources are repeatedly leaking a very large number of
\r
353 <dt class="option">ForceIncludeModules</dt>
\r
355 <p>In some rare cases, it may be necessary to include a module in leak detection, but it may not be possible to
\r
356 include <span class="filename">vld.h</span> in any of the module's sources. In such cases, this option can be
\r
357 used to force VLD to include those modules in leak detection. List the names of the modules (DLLs) to be
\r
358 forcefully included in leak detection. If you do use this option, it's advisable to also add
\r
359 <span class="filename">vld.lib</span> to the list of library modules in the linker options of your project's
\r
362 <p class="note"><strong>Caution:</strong> Use this option only when absolutely necessary. In some situations,
\r
363 use of this option may result in unpredictable behavior including false leak reports and/or crashes. It's
\r
364 best to stay away from this option unless you are sure you understand what you are doing.</p>
\r
367 <dt class="option">MaxDataDump</dt>
\r
369 <p>Set this option to an integer value to limit the amount of data displayed in memory block data dumps. When
\r
370 this number of bytes of data have been dumped, the dump will stop. This can be useful if any of the leaked
\r
371 blocks are very large and the debugger's output window becomes too cluttered. You can set this option to 0
\r
372 (zero) if you want to suppress data dumps altogether.</p>
\r
375 <dt class="option">MaxTraceFrames</dt>
\r
377 <p>By default, VLD will trace the call stack for each allocated block as far back as possible. Each frame traced
\r
378 adds additional overhead (in both CPU time and memory usage) to your debug executable. If you'd like to limit
\r
379 this overhead, you can define this macro to an integer value. The stack trace will stop when it has traced
\r
380 this number of frames. The frame count may include some of the "internal" frames which, by default, are not
\r
381 displayed in the debugger's output window (see <span class="option">TraceInternalFrames</span> below). In
\r
382 some cases there may be about three or four "internal" frames at the beginning of the call stack. Keep this
\r
383 in mind when using this macro, or you may not see the number of frames you expect.</p>
\r
386 <dt class="option">ReportEncoding</dt>
\r
388 <p>When the memory leak report is saved to a file, the report may optionally be Unicode encoded instead of using
\r
389 the default ASCII encoding. This might be useful if the data contained in leaked blocks is likely to consist
\r
390 of Unicode text. Set this option to "unicode" to generate a Unicode encoded report.</p>
\r
393 <dt class="option">ReportFile</dt>
\r
395 <p>Use this option to specify the name and location of the file in which to save the memory leak report when
\r
396 using a file as the report destination, as specified by the <span class="option">ReportTo</span> option. If
\r
397 no file is specified here, then VLD will save the report in a file named "memory_leak_report.txt" in the
\r
398 working directory of the program.</p>
\r
401 <dt class="option">ReportTo</dt>
\r
403 <p>The memory leak report may be sent to a file in addition to, or instead of, the debugger. Use this option to
\r
404 specify which type of destination to use. Specify one of "debugger" (the default), "file", or "both".</p>
\r
407 <dt class="option">SelfTest</dt>
\r
409 <p>VLD has the ability to check itself for memory leaks. This feature is always active. Every time you run VLD,
\r
410 in addition to checking your own program for memory leaks, it is also checking itself for leaks. Setting this
\r
411 option to "on" forces VLD to intentionally leak a small amount of memory: a 21-character block filled with
\r
412 the text "Memory Leak Self-Test". This provides a way to test VLD's ability to check itself for memory leaks
\r
413 and verify that this capability is working correctly. This option is usually only useful for debugging VLD
\r
417 <dt class="option">SlowDebuggerDump</dt>
\r
419 <p>If enabled, this option causes Visual Leak Detector to write the memory leak report to the debugger's output
\r
420 window at a slower than normal rate. This option is specifically designed to work around a known issue with
\r
421 some older versions of Visual Studio where some data sent to the output window might be lost if it is sent
\r
422 too quickly. If you notice that some information seems to be missing from the memory leak report, try turning
\r
426 <dt class="option">StackWalkMethod</dt>
\r
428 <p>Selects the method to be used for walking the stack to obtain call stacks for allocated memory blocks. The
\r
429 default "fast" method may not always be able to successfully trace completely through all call stacks. In
\r
430 such cases, the "safe" method may prove to be more reliable in obtaining the full stack trace. The
\r
431 disadvantage with the "safe" method is that it is significantly slower than the "fast" method and will
\r
432 probably result in very noticeable performance degradation of the program being debugged. In most cases it
\r
433 should be okay to leave this option set to "fast". If you experience problems getting VLD to show call
\r
434 stacks, you can try setting this option to "safe".</p>
\r
436 <p>If you do use the "safe" method, and notice a significant performance decrease, you may want to consider
\r
437 using the <span class="option">MaxTraceFrames</span> option to limit the number of frames traced to a
\r
438 relatively small number. This can reduce the amount of time spent tracing the stack by a very large
\r
442 <dt class="option">StartDisabled</dt>
\r
444 <p>Set this option to "yes" to disable memory leak detection initially. This can be useful if you need to be
\r
445 able to selectively enable memory leak detection from runtime, without needing to rebuild the executable;
\r
446 however, this option should be used with caution. Any memory leaks that may occur before memory leak
\r
447 detection is enabled at runtime will go undetected. For example, if the constructor of some global variable
\r
448 allocates memory before execution reaches a subsequent call to <span class="function">VLDEnable</span>, then
\r
449 VLD will not be able to detect if the memory allocated by the global variable is never freed. Refer to the
\r
450 following section on <a href="#control">controlling leak detection at runtime</a> for details on using the
\r
451 runtime APIs which can be useful in conjunction with this option.</p>
\r
454 <dt class="option">TraceInternalFrames</dt>
\r
456 <p>This option determines whether or not all frames of the call stack, including frames internal to the heap,
\r
457 are traced. There will always be a number of frames on the call stack which are internal to Visual Leak
\r
458 Detector and C/C++ or Win32 heap APIs that aren't generally useful for determining the cause of a leak.
\r
459 Normally these frames are skipped during the stack trace, which somewhat reduces the time spent tracing and
\r
460 amount of data collected and stored in memory. Including all frames in the stack trace, all the way down into
\r
461 VLD's own code can, however, be useful for debugging VLD itself.</p>
\r
468 <h2 id="control">Controlling Leak Detection at Runtime</h2>
\r
470 <p>Using the default configuration, VLD's memory leak detection will be enabled during the entire run of your program.
\r
471 In certain scenarios it may be desirable to selectively disable memory leak detection in certain segments of your
\r
472 code. VLD provides simple APIs for controlling the state of memory leak detection at runtime. To access these APIs,
\r
473 include <span class="filename">vld.h</span> in the source file that needs to use them.</p>
\r
476 <dt class="api">VLDDisable</dt>
\r
478 <p>This function disables memory leak detection. After calling this function, memory leak detection will remain
\r
479 disabled until it is explicitly re-enabled via a call to VLDEnable.</p>
\r
481 <pre class="code">void VLDDisable (void);</pre>
\r
483 <h3>Arguments:</h3>
\r
485 <p>This function accepts no arguments.</p>
\r
487 <h3>Return Value:</h3>
\r
489 <p>None (this function always succeeds).</p>
\r
493 <p>This function controls memory leak detection on a per-thread basis. In other words, calling this function
\r
494 disables memory leak detection for only the thread that called the function. Memory leak detection will
\r
495 remain enabled for any other threads in the same process. This insulates the programmer from having to
\r
496 synchronize multiple threads that disable and enable memory leak detection. However, note also that this
\r
497 means that in order to disable memory leak detection process-wide, this function must be called from every
\r
498 thread in the process.</p>
\r
502 <dt class="api">VLDEnable</dt>
\r
504 <p>This function enables memory leak detection if it was previously disabled. After calling this function,
\r
505 memory leak detection will remain enabled unless it is explicitly disabled again via a call to
\r
508 <pre class="code">void VLDEnable (void);</pre>
\r
510 <h3>Arguments:</h3>
\r
512 <p>This function accepts no arguments.</p>
\r
514 <h3>Return Value:</h3>
\r
516 <p>None (this function always succeeds).</p>
\r
520 <p>This function controls memory leak detection on a per-thread basis. See the remarks for
\r
521 <span class="function">VLDDisable</span> regarding multithreading and memory leak detection for details.
\r
522 Those same concepts also apply to this function.</p>
\r
529 <h2 id="build">Building Visual Leak Detector from Source</h2>
\r
531 <p>Because Visual Leak Detector is open source, it can be built from source if you want to tweak it to your
\r
532 liking. The most difficult part about building VLD from source is getting your build environment correctly set up.
\r
533 But if you follow these instructions carefully, the process should be fairly painless.</p>
\r
536 <li>VLD depends on the Debug Help Library. This library is part of
\r
537 <a href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx">Debugging Tools for Windows</a> (DTfW).
\r
538 Download and install DTfW in order to install the required headers and libraries. I recommend installing version
\r
539 6.5 of DTfW. Newer versions may also work, but older versions will probably not work. Be sure to manually select
\r
540 to install the SDK files during the DTfW installation or the headers and libraries will not be installed (they
\r
541 are not installed with a default installation).</li>
\r
543 <li>Visual C++ will need to be made aware of where it can find the Debug Help Library header and library files.
\r
544 Add the <span class="filename">sdk\inc</span> and <span class="filename">sdk\lib</span> subdirectories from the
\r
545 DTfW installation directory to the include and library search paths in Visual C++. (See the section above
\r
546 on <a href="#use">using Visual Leak Detector</a> on instructions for adding to these search paths).
\r
549 <li>VLD also requires a reasonably up-to-date Platform SDK. It is known to work with the latest SDK (as of this
\r
550 writing) which is the Windows Server 2003 R2 SDK. It should also work with earlier SDKs, such as the Windows XP
\r
551 SP2 SDK or may even work with SDKs as old as the February 2003 SDK. If in doubt,
\r
552 <a href="http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en">update
\r
553 your Platform SDK</a> to the latest version.</li>
\r
555 <li>Again, Visual C++ will need to know where to find the Platform SDK headers and libraries. Add the
\r
556 <span class="filename">Include</span> and <span class="filename">Lib</span> subdirectories from the
\r
557 Platform SDK installation directory to the Include and Library search paths, respectively. The
\r
558 Platform SDK directories should be placed just after the DTfW directories.</li>
\r
561 <p>To summarize, your Visual C++ include search path should look something like this:</p>
\r
563 <ul class="vcsearchpath">
\r
564 <li>C:\Program Files\Debugging Tools for Windows\sdk\inc</li>
\r
566 <li>C:\Program Files\Microsoft Platform SDK\Include</li>
\r
568 <li>C:\Program Files\Microsoft Visual Studio\VCx\Include</li>
\r
573 <p>And your Visual C++ library search path should look like this:</p>
\r
575 <ul class="vcsearchpath">
\r
576 <li>C:\Program Files\Debugging Tools for Windows\sdk\lib</li>
\r
578 <li>C:\Program Files\Microsoft Platform SDK\Lib</li>
\r
580 <li>C:\Program Files\Microsoft Visual Studio\VCx\Lib</li>
\r
585 <p>In the above examples, "VCx" could be "VC", "VC7", or "VC98" (or possibly other values) depending on which version of
\r
586 Visual Studio you have installed. Also, the name of your Platform SDK directory will probably be different from
\r
587 the example depending on which version of the Platform SDK you have installed.</p>
\r
589 <p>Once you have completed all of the above steps, your build environment should be ready. To build VLD, just open the
\r
590 <span class="filename">vld.sln</span> solution file and do a full build.</p>
\r
592 <p>When actually running the built project, <span class="filename">vld.dll</span> will expect to find the Debug Help
\r
593 Library as a private assembly. The private assembly must be located in the same directory as
\r
594 <span class="filename">vld.dll</span> (either the <span class="filename">Release</span> or
\r
595 <span class="filename">Debug</span> directory by default). Otherwise, when VLD is loaded, an error message will pop
\r
596 up indicating that the program failed to initialize, and you will see a message similar to the following in the
\r
597 debugger's output window:</p>
\r
598 <blockquote><p>LDR: LdrpWalkImportDescriptor() failed to probe C:\Projects\vld\Release\vld.dll for its manifest,
\r
599 ntstatus 0xc0150002</p></blockquote>
\r
601 <p>To ensure that <span class="filename">vld.dll</span> finds the required private assembly, you need to copy
\r
602 <span class="filename">dbghelp.dll</span> and <span class="filename">Microsoft.DTfW.DHL.manifest</span> to the
\r
603 same directory that <span class="filename">vld.dll</span> is in.</p>
\r
608 <h2 id="x64">Windows x64 Support</h2>
\r
610 <p>The VLD source code has been modified to add support for x64-based 64-bit Windows. However, the binary contained in
\r
611 the distributed version of VLD is 32-bit only. To take advantage of the 64-bit support, you'll need to build a 64-bit
\r
612 version of VLD from source. To build the 64-bit version, follow the instructions for <a href="#build">building VLD
\r
613 from source</a>. So long as it is built using a x64-compatible compiler in 64-bit mode, the resulting DLL will be a
\r
616 <p class="note"><strong>Note:</strong> I have not personally tested the 64-bit extensions so they are not absolutely
\r
617 guaranteed to work out-of-the-box. There may be a few lingering 64-bit compiler errors that still need to be worked
\r
618 out. If you need 64-bit support and run into problems trying to build the source in 64-bit mode, please
\r
619 <a href="mailto:dmoulding@gmail.com">let me know</a>. I'll be glad to assist in getting the 64-bit code working
\r
625 <h2 id="faq">Frequently Asked Questions</h2>
\r
628 <dt>When I try to compile my program with VLD, it fails and the compiler gives this error: <strong>Cannot open include file:
\r
629 'vld.h': No such file or directory</strong>.</dt>
\r
631 <p>The compiler can't find the header file that VLD installed. This probably means that VLD's include
\r
632 subdirectory has not been added to the Visual C++ include search path. See the section above about
\r
633 <a href="#use">Using Visual Leak Detector</a> for instructions on how to add VLD's directories to the search
\r
636 <dt>In the memory leak report, the callstack contains many lines that say
\r
637 <strong>"File and line number unvailable"</strong> or <strong>"Function name unavailable"</strong>.</dt>
\r
639 <p>This may mean that VLD couldn't find the symbol database for your program. The symbol database is ususally in
\r
640 a file named <span class="filename">[my-program-name].pdb</span>. If this file is not located in the same
\r
641 directory as the program itself, then VLD will probably not find it and can't show any file or function
\r
649 <h2 id="restrictions">Known Restrictions</h2>
\r
651 <p>Known restrictions/limitations in this version of VLD include:</p>
\r
654 <li>Memory allocations made through calls to functions loaded from a DLL using delayed loading may not be
\r
657 <li>Support for programs that use MFC 7.0 or MFC 7.1 is not complete yet. Some memory leaks from such MFC-based
\r
658 programs may not be detected. A possible workaround for this restriction is to try forcefully including the MFC
\r
659 DLLs in memory leak detection, by setting the <span class="option">ForceIncludeModules</span> configuration
\r
660 option to: "mfc70d.dll mfc71d.dll" and explicitly adding <span class="filename">vld.lib</span> as an input file
\r
661 on the linker command line (can be added through project settings by adding it to the list of library modules in
\r
662 the linker options). This restriction does not apply to programs that use MFC 4.2 or MFC 8.0 which are both fully
\r
665 <li>Visual Leak Detector may report leaks internal to Visual Leak Detector if the main thread of the process
\r
666 terminates while other threads are still running.</li>
\r
668 <li>On Windows 2000 and earlier operating systems, you may need to manually add the
\r
669 <span class="filename">bin\Microsoft.VC80.CRT</span> subdirectory from the Visual Leak Detector installation
\r
670 directory to the system PATH environment variable. Also, <span class="filename">dbghelp.dll</span> will probably
\r
671 need to be manually copied to the directory where the program being debugged resides. Otherwise the system may
\r
672 not find the required DLLs when running VLD.</li>
\r
674 <li>If more than one copy of the same C Runtime DLL is loaded in the process at the same time, then some leaks may
\r
675 go undetected (note that loading more than one copy of the C Runtime DLL at the same time is probably a bad idea
\r
676 to begin with).</li>
\r
682 <h2 id="license">License</h2>
\r
684 <p>Visual Leak Detector is distributed under the terms of the
\r
685 <a href="http://www.gnu.org/copyleft/lesser.html">GNU Lesser General Public License</a>. This license allows you to
\r
686 use the VLD library with your own programs without restriction. However, if you build a program (or another library)
\r
687 that is <em>based</em> on the VLD source code, or uses parts of the VLD source code in it, then some restrictions
\r
688 will apply. What this means is that you are free to ship and use the distributed version of the VLD DLL with regular
\r
689 commercial programs. But if you create a modified version of VLD, that modified version must remain "free software".
\r
690 See the <span class="filename"><a href="COPYING.txt">COPYING.txt</a></span> file for details.</p>
\r
692 <p>The Debug Help Library (<span class="filename">dbghelp.dll</span>) and Microsoft C Runtime Library
\r
693 (<span class="filename">msvcr80.dll</span>) distributed with this software are not part of
\r
694 Visual Leak Detector and are not covered under the terms of the GNU Lesser General Public License. They are
\r
695 separately copyrighted works of Microsoft Corporation. Microsoft reserves all its rights to its copyrights in the
\r
696 Debug Help Library and Microsoft C Runtime Library. Neither your use of the Visual Leak Detector software,
\r
697 nor your license under the GNU Lesser General Public license grant you any rights to use the Debug Help Library or
\r
698 Microsoft C Runtime Library in <strong>ANY WAY</strong> (for example, redistributing them) that would infringe upon
\r
699 Microsoft Corporation's copyright in the Debug Help Library or Microsoft C Runtime Library.</p>
\r
701 <h3>NO WARRANTY</h3>
\r
703 <p>BECAUSE VISUAL LEAK DETECTOR ("THE SOFTWARE") IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE SOFTWARE, TO
\r
704 THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
\r
705 PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
\r
706 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
\r
707 QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
\r
708 NECESSARY SERVICING, REPAIR OR CORRECTION.</p>
\r
710 <p>IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY
\r
711 WHO MAY MODIFY AND/OR REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE LICENSING TERMS SET FORTH ABOVE, BE LIABLE TO YOU
\r
712 FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY
\r
713 TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED
\r
714 BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR
\r
715 OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.</p>
\r
720 <h2 id="contact">Contacting the Author</h2>
\r
722 <p>Please forward any bug reports, questions, comments or suggestions to me at
\r
723 <a href="mailto:dmoulding@gmail.com">dmoulding@gmail.com.</a></p>
\r
725 <p>Donations to help support ongoing development of Visual Leak Detector are very appreciated!</p>
\r
727 <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
\r
729 <input type="hidden" name="cmd" value="_s-xclick" />
\r
730 <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!" />
\r
731 <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+YcxggGaMIIBlgIBATCBlDCBjjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1Nb3VudGFpbi
\r
732 BWaWV3MRQwEgYDVQQKEwtQYXlQYWwgSW5jLjETMBEGA1UECxQKbGl2ZV9jZXJ0czERMA8GA1UEAxQIbGl2ZV9hcGkxHDAaBgkqhkiG9w0BCQEWDXJlQHBheXBhbC5jb20CAQAwCQYFKw4DAhoFAKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDgwMTE5NDQ0NlowIwYJKoZIhvcNAQkEMRYEFKLDwHJFsU6L329159saLBrfszYcMA0GCSqGSIb3DQEBAQUABIGAe4Mjshnc1RvJU9zF6nL8zPJ+nHO2ct1CbS1WFkQMWvh2NTwlIVSZFWSLJQZ32kNoyseoxUvE587qdBKyMOATXjchDeMr1y815+GWE6Ffqw3rWw/ytfVEtEJd4yUUq0gHqFACul4nWM5zP5A3zkLZEVN3gAmX1eLbMIcSCKuVafM=-----END PKCS7-----" />
\r
736 <p id="compliance">
\r
737 <a href="http://validator.w3.org"><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" /></a>
\r
738 <a href="http://jigsaw.w3.org/css-validator"><img id="valid-css" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!" /></a>
\r
741 <p id="copyright">Copyright © 2005-2006 Dan Moulding</p>
\r
743 </div> <!-- #content -->
\r
projects / lyx.git / blob