forked from mozilla/mozilla-central
/
leaky.html
224 lines (179 loc) · 6.9 KB
/
leaky.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
<!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 a lot 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 a lot 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>