CHANGES.txt

Visual Leak Detector (VLD) Version 1.9h (beta)

  Change Log / Release Notes

1.9h beta (24 February 2009)
----------------------------
  Enhancements:
  + Added support to work with Visual Studio 2008.

  Known Bugs/Restrictions:
  + Same bugs/restrictions as version 1.9f.


1.9g beta (16 April 2008)
----------------------------
  Bugs Fixed:
  + Another deadlock condition may occur when loading DLLs into the process
    being debugged. Special thanks to Eric Bissonnette and Kristian Paradis for
    contributing this patch.

  Known Bugs/Restrictions:
  + Same bugs/restrictions as version 1.9f.


1.9f beta (18 November 2006)
----------------------------
  Bugs Fixed:
  + Deadlocks or access violations may occur when loading DLLs into
    multithreaded processes.

  + In multithreaded programs, if the main thread terminates before other
    threads in the process, then Visual Leak Detector may cause an access
    violation while generating the memory leak report.
    
  Known Bugs/Restrictions:
  + Memory allocations made through calls to functions loaded from a DLL using
    delayed loading may not be detected.

  + Support for programs that use MFC 7.0 or MFC 7.1 is not complete yet. Some
    memory leaks from such MFC-based programs may not be detected.

  + Visual Leak Detector may report leaks internal to Visual Leak Detector
    if the main thread of the process terminates while other threads are still
    running.

  + If more than one copy of the same C Runtime DLL is loaded in the process at
    the same time, then some leaks may go undetected (note that loading more
    than one copy of the C Runtime DLL into a process at the same time is
    probably a bad idea to begin with).

  
1.9e beta (16 November 2006)
----------------------------
  New Features/Enhancements:
  + Added a master on/off switch configuration option to vld.ini that can be
    used to completely disable Visual Leak Detector.
    
  Bugs Fixed:
  + Numerous deadlock situations. The multithread synchronization scheme has
    been completely re-written which should make deadlocks in VLD much less
    likey to happen.

  + An access violation will occur in VLD if GetProcAddress is called to obtain
    an export's address by ordinal, for certain libraries.

  + Problems may potentially occur when the program being debugged exits due to
    the Debug Help Library having been detached from the process too early.
    Symptoms might include access violation exceptions or other erratic behavior
    just as the program exits and while VLD is generating the leak report.

  + The copy of vld.ini installed in VLD's installation directory overrides any
    other copies of vld.ini that are created, even copies placed in the
    working directory of the program being debugged.
    
  Known Bugs/Restrictions:
  + Memory allocations made through calls to functions loaded from a DLL using
    delayed loading may not be detected.

  + Support for programs that use MFC 7.0 or MFC 7.1 is not complete yet. Some
    memory leaks from such MFC-based programs may not be detected.

  + If more than one copy of the same C Runtime DLL is loaded in the process at
    the same time, then some leaks may go undetected (note that loading more
    than one copy of the C Runtime DLL into a process at the same time is
    probably a bad idea to begin with).

  
1.9d beta (12 November 2006)
----------------------------
  Bugs Fixed:
  + Failed assertion "freed == TRUE" pops up when running a program with VLD
    without the debugger attached.

  + Some, but not all, multithreaded programs that dynamically load and unload
    many DLLs have been known to experience problems, such as deadlocks or
    exceptions, when used with VLD.

  + Failed assertion "exportmodule != NULL" pops up when running some programs
    with VLD.

  + VLD fails to show file names or function names in the memory leak report for
    some programs that are linked with the dynamic CRT library.

  + Access violation exceptions are thrown, but caught by the operating system,
    when running some programs with VLD.


1.9c beta (6 November 2006)
---------------------------
  New Features/Enhancments:
  + New NSIS installer makes setting up and using VLD much easier.

  + No need to manually copy dbghelp.dll to the right location, VLD will always
    find the right version.

  + MFC 8.0 is now fully supported.

  + The memory leak report is now written to the output window much faster.
    Support has been added, through a new configuration option, to slow down
    the report output for older versions of Visual Studio that have trouble
    when it is written too quickly.
  
  Bugs Fixed:
  + All known compatibilities with Visual Studio 2005 have been eliminated.

  + Leaks from calloc may go undetected.

  + Leaks from vector new operator may go undetected.

  + VLDDisable and VLDEnable do not work as expected; some memory leaks that
    should be ignored by VLD due to a previous call to VLDDisable are still
    reported.

  + Unloading and reloading a previously loaded module may cause leaks that
    occur in the module after it was reloaded to go undetected.

  + If vld.h is included in a release build, then the compiler will generate
    errors if the VLDEnable or VLDDisable APIs have been used.


1.9b beta (26 October 2006)
---------------------------
  Bugs Fixed:
  + Source compiles under Visual Studio 2005 and the binaries are compatible
    with applications that link with the Visual Studio 2005 C Runtime Library
    (msvcr80d.dll).

  Known Restrictions in this Release:
  + Memory allocations made through calls to functions loaded from a DLL using
    delayed loading may not be detected.

  + Support for programs that use MFC 7.0, MFC 7.1, or MFC 8.0 is not complete
    yet. Some memory leaks from such MFC-based programs may not be detected. A
    workaround for this restriction is to forcefully include the MFC DLLs in
    memory leak detection, by setting the "ForceIncludeModules" configuration
    option to: "mfc70d.dll mfc71d.dll mfc80d.dll" and explicitly adding vld.lib
    as an input file on the linker command line (can be added through project
    settings by adding it to the list of library modules in the linker options).
    This restriction does not apply to programs that use MFC 4.2, which is fully
    supported.


1.9a beta (9 March 2006)
------------------------
  New Features/Enhancments:
  + All new leak detection engine detects most, if not all, in-process memory
    leaks, not just leaks from "new" or "malloc", including COM-based leaks.

  + Packaged as an easier-to-use DLL. There's no longer any need to carefully
    decide which modules should be linked with the VLD library. Instead, you
    just include the vld.h header file in at least one source file from each
    module (DLL or EXE) to be included in memory leak detection.

  + Configuration is done from an INI file instead of using preprocessor macros.
    This allows VLD's configuration to be changed without needing to recompile
    the program.

  + Many new configuration options have been added. One of the most often
    requested option that has been added is the option to save the leak report
    to a file instead of, or in addition to, the debugger.

  Bugs Fixed:
  + The improved design of the new leak detection engine has resolved all of the
    previously known restrictions in version 1.0.

  Known Restrictions in this Release:
  + Memory allocations made through calls to functions loaded from a DLL using
    delayed loading may not be detected.

  + Support for programs that use MFC 7.0, MFC 7.1, or MFC 8.0 is not complete
    yet. Some memory leaks from such MFC-based programs may not be detected. A
    workaround for this restriction is to forcefully include the MFC DLLs in
    memory leak detection, by setting the "ForceIncludeModules" configuration
    option to: "mfc70d.dll mfc71d.dll mfc80d.dll" and explicitly adding vld.lib
    as an input file on the linker command line (can be added through project
    settings by adding it to the list of library modules in the linker options).
    This restriction does not apply to programs that use MFC 4.2, which is fully
    supported.


1.0 (5 August 2005)
-------------------
  New Features/Enhancements:
  + Memory leak detection can now be selectively disabled and enabled at
    runtime, using provided APIs. This provides a straightforward way of
    allowing VLD to selectively "ignore" certain allocations. It can also be
    used to disable VLD altogether at runtime, improving application performance
    without needing to recompile.

  + If there are multiple identical memory leaks (i.e. leaks that originate from
    the same call stack and that leak the same size memory block) then VLD can
    optionally aggregate all of the repeated leaks, showing only the first such
    leaked block in detail in the memory leak report. A tally of the total
    number of leaks that match that particular size and call stack accompanies
    the information for that leak.

  + When VLD is initialized at program startup, the library type which was
    linked-in is displayed. This can help verify that the expected VLD library
    (either single-threaded static, multithreaded static, or multithreaded DLL)
    is being linked with your program.

  + The Visual Leak Detector name is displayed on most messages output to the
    debugger to easily differentiate VLD's output from the output produced by
    the built-in memory leak detector.

  + If any of the compile-time configuration options have been changed from
    their default values, then the current state of the option is displayed in
    the debugger when VLD is initialized.

  + VLD's memory leak self-checking capability (checking for leaks in VLD
    itself) can be verified using a new preprocessor macro that allows VLD to
    perform a self-test at runtime.

  Bugs Fixed:
  + If the MFC libraries are statically linked to the program being debugged,
    then MFC will erroneously report memory leaks in the Visual Leak Detector
    code and may cause an access violation while attempting to report the false
    memory leaks. These bogus leaks are always reported as "client block at
    <address>, subtype bf42" and are claimed to be "invalid objects".

  + VLD will leak a fixed-sized block of memory when the program exits if VLD
    failed to initialize because the Debug Help library (dbghelp.dll) could not
    be loaded.

  + In multithreaded programs, if the program's main thread terminates before
    other threads in the same process, then VLD may cause an access violation
    while freeing resources used internally by VLD.


0.9i beta (30 April 2005)
-------------------------
  New Features/Enhancements:
  + Added support in the source code for x64 architecture. The pre-built
    libraries will continue to support 32-bit only. If you need 64-bit support
    you'll need to build 64-bit versions of the libraries from source. Note that
    x64 is the only 64-bit architecture supported at this time. Itanium (aka
    IA-64) is NOT currently supported.

  Bugs Fixed:
  + VLD does not report memory leaks that are the result of a failure to free
    memory allocated via a call to realloc().
  + In multithreaded programs, if the program's main thread terminates before
    other threads in the same process, then VLD may cause an access violation
    while checking for memory leaks.
  + If VLD cannot find the source file and line number information for a program
    address, the last known file and line number will be repeated in the call
    stack section of the memory leak report. The correct behavior should be for
    VLD to print "File and line number not available" for that call stack entry.


0.9h beta (22 April 2005)
-------------------------
  Bugs Fixed:
  + Access Violations occur at random places within the VLD code when using
    VLD version 0.9g.
  + When using VLD version 0.9g, VLD may fail to report some memory leaks.


0.9g beta (22 April 2005)
-------------------------
  New Features/Enhancements:
  + Replaced the temporary internal search algorithm with a permanent search
    algorithm that is much faster. Programs that dynamically allocate a large
    number of memory blocks (tens of thousands or more) will see the most
    significant performance boost from this version of VLD versus the previous
    version. Overall, this is the fastest version of VLD released to date.


0.9f beta (13 April 2005)
-------------------------
  New Features/Enhancements:
  + Changed the internal search algorithm to a temporary simpler, but
    more stable algorithm. A permanent algorithm which should be much
    more efficient will be in a forthcoming release.

  Bugs Fixed:
  + Access Violation at line 319 in vldutil.cpp may occur when running a
    program linked with the VLD library.


0.9e beta (12 April 2005)
-------------------------
  New Features/Enhancements:
  + VLD no longer uses any STL containers or STL strings. This solves all of the
    compatibility problems with Visual Studio .NET when using the pre-built
    VLD libraries.

  + The configuration preprocessor macros now work with C programs without the
    need to call VLDConfigure from within the program being debugged.
    Because VLDConfigure is now obsolete, it has been removed.

  + One new source file (vldutil.cpp) and one new header (vldutil.h) have been
    added. They contain utility functions and utility classes that replace
    functionality previously performed by STL containers and strings.

  + The VisualLeakDetector global class object is now constructed at C runtime
    initialization (i.e. it resides in the "compiler" initialization area).
    Because VLD no longer uses any STL components, there is no longer the risk
    that VLD will conflict with any STL libraries that also are constructed at
    C runtime initialization. The end result is that VLD starts running earlier
    and is destroyed later, which leads to more accurate leak detection.

  Bugs Fixed:
  + Linking to the VLD 0.9d libraries from the VLD distribution under Visual
    Studio .NET results in a number of linker "unresolved external symbol"
    errors. Unresolved symbols include "__declspec(dllimport) void __cdecl
    std::_Xran(void)" and "__declspec(dllimport) private: void __thiscall
    std::basic_string,class std::allocator >::_Eos(unsigned int)", among others.

  + Call stacks do not appear in the memory leak report when linking against
    release VLD libraries built from source with Visual Studio .NET.

  + If the preprocessor macro VLD_MAX_DATA_DUMP is defined as 0 (zero), then VLD
    will get stuck in an infinite loop, repeatedly printing the same information
    while attempting to display the memory leak report in the debugger's output
    window.


0.9d beta (30 March 2005)
-------------------------
  New Features/Enhancements:
  + This version of VLD brings with it some major changes to the way VLD
    interfaces with programs that use it. Instead of requiring that VLD be built
    from source and then linked with the application, VLD is now packaged as a
    pre-built static library. For those who just want to use VLD and are not
    interested in modifying the source, this eliminates the complexities of
    building VLD from source. A single header file, vld.h, has been added. To
    link with the static library, this header needs to be included in one of the
    program's source files. Please see the README.txt file for details on how
    these changes affect how to use Visual Leak Detector.

  + The Microsoft Debug Help Library (dbghelp.dll) version 6.3 is now included
    with the VLD distribution.


0.9c beta (17 March 2005)
-------------------------
  Bugs Fixed:
  + Compile error, "error C2039: 'size' : is not a member of '_CrtMemBlockHeader'"
    occurs at line 644 of vld.cpp when building VLD with the VLD_MAX_DATA_DUMP
    preprocessor macro defined.


0.9b beta (15 March 2005)
-------------------------
  Bugs Fixed:
  + VLD fails to detect memory leaks in class constructors if the objects
    constructed are global objects.

  + If a debug executable is built with certain compiler optimizations turned on,
    specifically frame pointer omission optimization or automatic inlining, then
    theoretically VLD may produce incomplete or inaccurate stack traces or might
    fail to produce stack traces altogether.


0.9a beta (12 March 2005)
-------------------------
  Initial Public Release