mirror of
https://git.lyx.org/repos/lyx.git
synced 2024-09-20 06:49:56 +00:00
c0708a5c5e
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21911 a592a061-630c-0410-9148-cb99ea01b6c8
345 lines
16 KiB
Plaintext
345 lines
16 KiB
Plaintext
Visual Leak Detector (VLD) Version 1.9f (beta)
|
|
|
|
Change Log / Release Notes
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|