canmove, Confirmed users, Bureaucrats and Sysops emeriti
1,334
edits
Performance:Leak Tools: Difference between revisions
reorganize the tools section
(add a few sections) |
(reorganize the tools section) |
||
| Line 1: | Line 1: | ||
== What leak tools do we have? == | == What leak tools do we have? == | ||
=== [http://mozilla.org/performance/refcnt-balancer.html Refcount balancer] === | === Leak tools for large object graphs === | ||
==== leak-gauge ==== | |||
Leak gauge is a script (available as a [http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.pl?raw=1 perl script] or as [http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.html?raw=1 HTML and JavaScript that must be run from a local file]) that post-processes an log taken by setting environment variables in a release build. It is designed to assist in detecting what leaks of large object graphs occur during normal browsing activity. The logging can be run (as described in the script) during normal browsing without significant overhead. Then the script can be run to provide information about the documents, window objects, and docshells that leaked. See [http://www.squarefree.com/2006/01/13/memory-leak-detection-tool/ Jesse Ruderman's blog entry] for more details including a list of other links. | |||
==== leak-monitor ==== | |||
[http://dbaron.org/mozilla/leak-monitor/ Leak Monitor] is an extension that detects (when closing windows) the primary ways in which JavaScript code can cause leaks that are not bugs in the native code core. (An example of such a bug would be registering (in each window) a JavaScript-implemented observer with the global observer service and never removing the observers, leaving JavaScript code running in the context of each window registered as an observer until the user quits the browser.) When a leak is detected, the extension presents the user (or application/extension developer!) with a dialog with information about the leaked objects. (The alerts can also be triggered by bugs in the core code. See the [http://dbaron.org/mozilla/leak-monitor/ extension's homepage] for more details.) | |||
==== Cycle Collector Debugging (DEBUG_CC) ==== | |||
=== Leak tools for medium-size object graphs === | |||
==== [http://mozilla.org/performance/refcnt-balancer.html Refcount balancer] ==== | |||
The refcount balancer consists of the [http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsTraceRefcntImpl.cpp nsTraceRefcnt] code in [http://lxr.mozilla.org/seamonkey/source/xpcom/base/ mozilla/xpcom/base/] and the perl scripts in [http://lxr.mozilla.org/mozilla/source/tools/rb/ mozilla/tools/rb/]. It works by instrumenting refcounting, so every AddRef and Release method created using NS_IMPL_ISUPPORTSn and variants, NS_IMPL_ADDREF, or NS_IMPL_RELEASE is automatically instrumented. It also logs information for non-refcounted objects instrumented using the MOZ_COUNT_CTOR and MOZ_COUNT_DTOR macros. | The refcount balancer consists of the [http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsTraceRefcntImpl.cpp nsTraceRefcnt] code in [http://lxr.mozilla.org/seamonkey/source/xpcom/base/ mozilla/xpcom/base/] and the perl scripts in [http://lxr.mozilla.org/mozilla/source/tools/rb/ mozilla/tools/rb/]. It works by instrumenting refcounting, so every AddRef and Release method created using NS_IMPL_ISUPPORTSn and variants, NS_IMPL_ADDREF, or NS_IMPL_RELEASE is automatically instrumented. It also logs information for non-refcounted objects instrumented using the MOZ_COUNT_CTOR and MOZ_COUNT_DTOR macros. | ||
| Line 7: | Line 21: | ||
Because it is based on instrumentation, it is not reliable for gathering aggregate statistics. (In spite of this, it is currently used for the leak stats on tinderbox, although a trace-malloc based replacement is in development.) However, it is by far the best tool we have for debugging leaks of reference counted objects, which are the leaks in Mozilla that can entrain the largest object graphs. | Because it is based on instrumentation, it is not reliable for gathering aggregate statistics. (In spite of this, it is currently used for the leak stats on tinderbox, although a trace-malloc based replacement is in development.) However, it is by far the best tool we have for debugging leaks of reference counted objects, which are the leaks in Mozilla that can entrain the largest object graphs. | ||
These tools | These tools on Windows, Mac (PPC and Intel), and Linux (x86), although nsCOMPtr logging doesn't work on Windows (?) and Mac and Linux stack traces require some post-processing (see below). In optimized builds they can be built with --enable-logrefcnt. | ||
See below for a detailed description of how to use the refcount balancer effectively. | See below for a detailed description of how to use the refcount balancer effectively. | ||
=== Trace-malloc === | === Leak tools for simple objects and summary statistics === | ||
==== Trace-malloc ==== | |||
The trace-malloc code consists of the nsTraceMalloc code in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/lib/ mozilla/tools/trace-malloc/lib/] and the perl scripts and trace-malloc readers in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/ mozilla/tools/trace-malloc/]. It works by overriding / hooking into malloc and free (and related functions) and logging all calls, with stacks. It is probably the best tool we currently have for gathering aggregate memory usage statistics. It is generally more useful for bloat measurement than leak measurement, but it can be used to find leaks. It works on Linux and | The trace-malloc code consists of the nsTraceMalloc code in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/lib/ mozilla/tools/trace-malloc/lib/] and the perl scripts and trace-malloc readers in [http://lxr.mozilla.org/mozilla/source/tools/trace-malloc/ mozilla/tools/trace-malloc/]. It works by overriding / hooking into malloc and free (and related functions) and logging all calls, with stacks. It is probably the best tool we currently have for gathering aggregate memory usage statistics. It is generally more useful for bloat measurement than leak measurement, but it can be used to find leaks. It works on Windows, Linux (x86), and Mac (PPC and Intel). It can be built by checking out mozilla/tools/trace-malloc/ and building with --enable-trace-malloc. | ||
'''Update''' (2003-06-16): There is a new trace-malloc tool, leaksoup, that is useful for finding leaks. See below for more information on how to use it. | '''Update''' (2003-06-16): There is a new trace-malloc tool, leaksoup, that is useful for finding leaks. See below for more information on how to use it. | ||
=== Boehm GC === | ==== Boehm GC ==== | ||
The Boehm GC is a garbage collector for C/C++ programs that can be used to debug leaks in a program that does not require a garbage collector. It can be used with leaksoup or leak-soup.pl to find the roots of graphs of leaked objects. The leak detection tools find leaks using garbage collection while the app is running (which tends to hide many of the largest leaked object graphs, which can usually be reached through global variables). Some #defines can be flipped in xpcom/base/nsLeakDetector.cpp to cause it to print out all objects leaked at shutdown (into a different file). These shutdown leaks will include both one-time shutdown leaks (which aren't really a serious problem, but make it harder to find real leaks) and real leaks that had previously been rooted (as far as the GC was concerned) through a global variable. Some of the trace-malloc tools imitate its output format and therefore some of the processing tools are compatible. It works on Mac (Classic) and Linux (although slightly better on Mac). On Linux it can be built with --enable-boehm. On Mac, (?). | The Boehm GC is a garbage collector for C/C++ programs that can be used to debug leaks in a program that does not require a garbage collector. It can be used with leaksoup or leak-soup.pl to find the roots of graphs of leaked objects. The leak detection tools find leaks using garbage collection while the app is running (which tends to hide many of the largest leaked object graphs, which can usually be reached through global variables). Some #defines can be flipped in xpcom/base/nsLeakDetector.cpp to cause it to print out all objects leaked at shutdown (into a different file). These shutdown leaks will include both one-time shutdown leaks (which aren't really a serious problem, but make it harder to find real leaks) and real leaks that had previously been rooted (as far as the GC was concerned) through a global variable. Some of the trace-malloc tools imitate its output format and therefore some of the processing tools are compatible. It works on Mac (Classic) and Linux (although slightly better on Mac). On Linux it can be built with --enable-boehm. On Mac, (?). | ||
| Line 31: | Line 40: | ||
'''Update (2006-06-13): The code integrating the Boehm GC in Mozilla has not been tested for a number of years and is unlikely to work anymore.''' | '''Update (2006-06-13): The code integrating the Boehm GC in Mozilla has not been tested for a number of years and is unlikely to work anymore.''' | ||
=== Purify === | ==== Purify ==== | ||
Purify is a commercial tool that detects a number of types of problems, including leaks. I think it works internally rather like the Boehm GC. That is, it reports a subset of real leaks during the running of the app (while hiding many real leaks because they are rooted through globals), and then reports all leaks at shutdown. Things it reports as potential leaks (PLKs) should be ignored -- they just mean that an object is being held only by an pointer to an offset within it (which happens when an XPCOM object implements multiple interfaces (that don't inherit from each other) and is held only by a pointer to an interface other than the first). It is available on Windows and Solaris. | Purify is a commercial tool that detects a number of types of problems, including leaks. I think it works internally rather like the Boehm GC. That is, it reports a subset of real leaks during the running of the app (while hiding many real leaks because they are rooted through globals), and then reports all leaks at shutdown. Things it reports as potential leaks (PLKs) should be ignored -- they just mean that an object is being held only by an pointer to an offset within it (which happens when an XPCOM object implements multiple interfaces (that don't inherit from each other) and is held only by a pointer to an interface other than the first). It is available on Windows and Solaris. | ||
=== Valgrind | ==== Valgrind ==== | ||
[http://valgrind.org/ Valgrind] is a free tool for Linux that (like Purify) detects a number of program errors at runtime. Like Purify, its leak reporting is only useful for the simplest types of leaks (those not involving reference counting or large object graphs). | [http://valgrind.org/ Valgrind] is a free tool for Linux that (like Purify) detects a number of program errors at runtime. Like Purify, its leak reporting is only useful for the simplest types of leaks (those not involving reference counting or large object graphs). | ||
=== Apple tools | ==== Apple tools ==== | ||
Apple provides [http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html some tools] for Mac OS X that probably report similar problems to those reported by Purify and Valgrind. | Apple provides [http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html some tools] for Mac OS X that probably report similar problems to those reported by Purify and Valgrind. | ||
| Line 84: | Line 93: | ||
== Getting symbol information for system libraries == | == Getting symbol information for system libraries == | ||
=== Windows === | |||
Setting the environment variable <code>_NT_SYMBOL_PATH</code> to something like <code>symsrv*symsrv.dll*f:\localsymbols*http://msdl.microsoft.com/download/symbols</code> as described in [http://support.microsoft.com/kb/311503 Microsoft's article]. This needs to be done when running, since we do the address to symbol mapping at runtime. | |||
=== Linux === | |||
Many Linux distros provide packages containing external debugging symbols for system libraries. fix-linux-stack.pl uses this debugging information (although it does not verify that they match the library versions on the system). | |||
For example, on Fedora, these are in *-debuginfo RPMs (which are available in yum repositories that are disabled by default, but easily enabled by editing the system configuration). | |||
== Leak statistics on tinderbox == | == Leak statistics on tinderbox == | ||