mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-06 00:55:37 +00:00
225 lines
6.9 KiB
HTML
225 lines
6.9 KiB
HTML
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="GENERATOR" content="Mozilla/4.61 [en] (X11; I; Linux 2.2.5-22 i686) [Netscape]">
|
|
<title>Leaky</title>
|
|
</head>
|
|
<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF0000">
|
|
|
|
<center><b><font face="Arial,Helvetica"><font size=+2>Leaky</font></font></b></center>
|
|
|
|
<p>Leaky is a program which will help you find memory leaks, and as of
|
|
late, help you debug reference count problems with xpcom objects.
|
|
<p><b><font face="Arial,Helvetica"><font size=+2>Get the Source</font></font></b>
|
|
<p>Leaky is not currently part of the default SeaMonkey module,
|
|
<br>you will need to explicitly pull the source:
|
|
<br>
|
|
<pre> cvs checkout mozilla/tools/leaky</pre>
|
|
If there is enough demand, we can make this part of the default SeaMonkey
|
|
module.
|
|
<p><b><font face="Arial,Helvetica"><font size=+2>Building it</font></font></b>
|
|
<br>
|
|
<pre> ./configure --enable-leaky</pre>
|
|
Top-of-tree build should Just Build It and leaky will show up in dist/bin.
|
|
<p><b><font face="Arial,Helvetica"><font size=+2>Using Leaky</font></font></b>
|
|
<p>After it has been built, you can use TestPreload and TestMalloc and
|
|
ShowLibs to debug your implementation.
|
|
<p>By setting the <tt>LIBMALLOC_LOG</tt> environment variable you control
|
|
how much information is logged during the programs execution. See libmalloc.h
|
|
for a definition of the values to use. If you are using <tt>LD_PRELOAD</tt>,
|
|
here is one way to run your program:
|
|
<blockquote><tt>env LD_PRELOAD=/full/path/to/libleaky.so LIBMALLOC_LOG=1
|
|
my-program</tt></blockquote>
|
|
The debugging malloc library creates two files, <tt>malloc-log</tt> and
|
|
<tt>malloc-map</tt>.
|
|
The malloc-log file can be quite large for large programs (e.g. mozilla)
|
|
so be prepared to have alot of disk space. The malloc-map is tiny.
|
|
<p>Once your program has completed execution you can use leaky to look
|
|
for memory leaks, or at least use it to dump the log. For memory leaks,
|
|
you use leaky like this:
|
|
<blockquote><tt>leaky -d <program-name-goes-here> malloc-log</tt></blockquote>
|
|
Leaky will then display all of the call sites where memory was leaked.
|
|
To look at the entire log file contents, not just the leaks add "-a" to
|
|
the arguments:
|
|
<blockquote><tt>leaky -d -a <program-name-goes-here> malloc-log</tt></blockquote>
|
|
For debugging reference count issues, here is what I do:
|
|
<ol>
|
|
<li>
|
|
Set LIBMALLOC_LOG to "8"</li>
|
|
|
|
<li>
|
|
Modify your source code so that your class::Addref and class::Release methods
|
|
call __log_addref and __log_release, as appropriate. See libmalloc.h for
|
|
their signatures. If you are using mozilla, you no longer need to modify
|
|
your source code with a debug build. See
|
|
<a href="http://lxr.mozilla.org/seamonkey/source/xpcom/doc/MemoryTools.html">
|
|
xpcom/doc/MemoryTools.html</a> for more info.
|
|
|
|
</li>
|
|
|
|
<li>
|
|
Run your program so that you get the log data. Its often convenient to
|
|
run your program in the debugger and then set a breakpoint at an interesting
|
|
location where you think some object is being leaked or over-freed. Then
|
|
when the debugger gets there tell it to execute DumpAddressMap. In gdb
|
|
you do this:</li>
|
|
|
|
<ol>
|
|
<br><tt>(gdb) p DumpAddressMap()</tt></ol>
|
|
|
|
<li>
|
|
Then use leaky to capture the addref and release calls to a log file:</li>
|
|
|
|
<ol>
|
|
<br><tt>leaky -d -a <program-name-goes-here> malloc-log > log</tt></ol>
|
|
|
|
<li>
|
|
Then use "grep" to search the log for a specific object by grepping for
|
|
its memory address...</li>
|
|
|
|
<li>
|
|
On a typical *short* run of mozilla, I'll end up with a malloc-log file
|
|
of around 5 to 10 megabytes and the resulting converted log file will be
|
|
10 to 20 times that so be prepared to have alot of disk space. It helps
|
|
a great deal to narrow down your problem space to reduce the log file size...</li>
|
|
</ol>
|
|
|
|
<p><br>Leaky now has a "graph" output option. If you do this:
|
|
<pre> leaky -gqx <program-name-goes-here> malloc-log | sed -e 's/&/&/g' > /tmp/GQ0.html</pre>
|
|
Then leaky will make a graph of the leaks [-g] and output that graph in
|
|
xml format (currently actually html...) [-x]. I use sed to make it legitimate
|
|
html and off it goes to a file.
|
|
<p>If you throw file at viewer (recursion is cool) then it will present
|
|
you with a treeview of the leaks that you can click on to open/close sections.
|
|
Enjoy!
|
|
<p><b><font face="Arial,Helvetica"><font size=+2>Command Line Options</font></font></b>
|
|
<br>
|
|
<table CELLSPACING=5 CELLPADDING=0 WIDTH="100%" NOSAVE >
|
|
<tr>
|
|
<td>-a</td>
|
|
|
|
<td>dump the entire log. This means all malloc's, free's, new's, delete's,
|
|
addref's or release's will be displayed</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-d</td>
|
|
|
|
<td>dump leaks (only one of -d, -R or -g can be used at a time)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-R</td>
|
|
|
|
<td>dump refcnts</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-g</td>
|
|
|
|
<td>display a graph of leaks</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-x</td>
|
|
|
|
<td>when displaying the graph with -g, use html output that can be fed
|
|
into an html4+css+dom compliant viewer (like mozilla :-)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-r symbol</td>
|
|
|
|
<td>define a root for the graph dump. nodes in the graph above symbol will
|
|
be hidden, thus reducing the depth of the graph making it easier to find
|
|
deeper leaks.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-e symbol</td>
|
|
|
|
<td>exclude leaks that include symbol from treatment</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-i symbol</td>
|
|
|
|
<td>include leaks that include symbol for treatment. If an includes are
|
|
defined than only leaks which include the symbols will be processed. excludes
|
|
will still apply to this reduced set of leaks</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-A</td>
|
|
|
|
<td>show the address in the stack crawls, not just the symobls</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-h num</td>
|
|
|
|
<td>set the size of the hash buckets used by leaksy dictionaries to <num></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-s depth</td>
|
|
|
|
<td>set the depth of the stack crawls shown when displaying stack crawls
|
|
(any of the dumping modes except -g)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>-q</td>
|
|
|
|
<td>make leaky quiet (don't dump the information about symbols being read
|
|
and from which libraries)</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p><b><font face="Arial,Helvetica"><font size=+2>Porting to non-Intel/Linux</font></font></b>
|
|
<br>
|
|
<p>Initial version works only on x86 linux. To work on other platforms
|
|
you will need to:
|
|
<ol>
|
|
<li>
|
|
Implement <tt>CrawlStack()</tt> in libmalloc.cpp</li>
|
|
|
|
<li>
|
|
Implement <tt>DumpAddressMap()</tt> in libmalloc.cpp and in ShowLibs.cpp</li>
|
|
|
|
<li>
|
|
Either support LD_PRELOAD in your dynamic linker, <b>or</b></li>
|
|
|
|
<br>produce a library that wraps your libc malloc (see config.h for some
|
|
clues)
|
|
<li>
|
|
Implement symbol table reading code (see coff.cpp, elf.cpp and bfd.cpp
|
|
for examples; at the time of writing this document only bfd.cpp was known
|
|
to work)</li>
|
|
</ol>
|
|
|
|
<hr><!-- hhmts start -->Last modified: Sun Sep 26 13:15:33 PDT 1999<!-- hhmts end -->
|
|
<br>Send comments to <i><a href="mailto:kipp@netscape.com">Kipp Hickman</a></i>
|
|
<br>
|
|
</body>
|
|
</html>
|