« back to all changes in this revision
Viewing changes to FAQ.txt
- browse files at revision 1.1.5
- compare with another revision
- download diff
- download tarball
- view history from revision 1.1.5
- Committer: Bazaar Package Importer
- Author(s): Sebastian Dröge
- Date: 2006-11-16 17:56:30 UTC
- mfrom: (1.2.2 upstream)
- mto: This revision was merged to the branch mainline in revision 14.
- Revision ID: james.westby@ubuntu.com-20061116175630-hatkgajb0twz0upw
Tags: upstream-3.2.1
Import upstream version 3.2.1
- files modified:
- FAQ.txt
added
removed
FAQ.txt
1
1
2
2
3
Release 3.1.0 November 15 2005
4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
Valgrind FAQ
4
Release 3.2.0 7 June 2006
5
~~~~~~~~~~~~~~~~~~~~~~~~~
5
6
6
7
Table of Contents
7
8
1. Background
16
17
1. Background
17
18
------------------------------------------------------------------------
18
19
19
1.1. How do you pronounce "Valgrind"?
20
21
The "Val" as in the world "value". The "grind" is pronounced with a
22
short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined"
23
(rhymes with "find").
24
25
Don't feel bad: almost everyone gets it wrong at first.
20
1.1. How do you pronounce "Valgrind"?
21
22
The "Val" as in the world "value". The "grind" is pronounced with a
23
short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined"
24
(rhymes with "find").
25
26
Don't feel bad: almost everyone gets it wrong at first.
26
27
27
28
------------------------------------------------------------------------
28
29
29
1.2. Where does the name "Valgrind" come from?
30
31
From Nordic mythology. Originally (before release) the project was
32
named Heimdall, after the watchman of the Nordic gods. He could "see a
33
hundred miles by day or night, hear the grass growing, see the wool
34
growing on a sheep's back" (etc). This would have been a great name,
35
but it was already taken by a security package "Heimdal".
36
37
Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the
38
name of the main entrance to Valhalla (the Hall of the Chosen Slain in
39
Asgard). Over this entrance there resides a wolf and over it there is
40
the head of a boar and on it perches a huge eagle, whose eyes can see
41
to the far regions of the nine worlds. Only those judged worthy by the
42
guardians are allowed to pass through Valgrind. All others are refused
43
entrance.
44
45
It's not short for "value grinder", although that's not a bad guess.
30
1.2. Where does the name "Valgrind" come from?
31
32
From Nordic mythology. Originally (before release) the project was named
33
Heimdall, after the watchman of the Nordic gods. He could "see a hundred
34
miles by day or night, hear the grass growing, see the wool growing on a
35
sheep's back" (etc). This would have been a great name, but it was
36
already taken by a security package "Heimdal".
37
38
Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the name
39
of the main entrance to Valhalla (the Hall of the Chosen Slain in
40
Asgard). Over this entrance there resides a wolf and over it there is
41
the head of a boar and on it perches a huge eagle, whose eyes can see to
42
the far regions of the nine worlds. Only those judged worthy by the
43
guardians are allowed to pass through Valgrind. All others are refused
44
entrance.
45
46
It's not short for "value grinder", although that's not a bad guess.
47
46
48
47
49
------------------------------------------------------------------------
48
50
2. Compiling, installing and configuring
49
51
------------------------------------------------------------------------
50
52
51
2.1. When I trying building Valgrind, 'make' dies partway with an
52
assertion failure, something like this:
53
54
% make: expand.c:489: allocated_variable_append:
55
Assertion 'current_variable_set_list->next != 0' failed.
53
2.1. When I trying building Valgrind, 'make' dies partway with an
54
assertion failure, something like this:
56
55
57
It's probably a bug in 'make'. Some, but not all, instances of version
58
3.79.1 have this bug, see
56
% make: expand.c:489: allocated_variable_append:
57
Assertion 'current_variable_set_list->next != 0' failed.
58
59
It's probably a bug in 'make'. Some, but not all, instances of version
60
3.79.1 have this bug, see
59
61
www.mail-archive.com/bug-make@gnu.org/msg01658.html. Try upgrading to a
60
more recent version of 'make'. Alternatively, we have heard that
61
unsetting the CFLAGS environment variable avoids the problem.
62
more recent version of 'make'. Alternatively, we have heard that
63
unsetting the CFLAGS environment variable avoids the problem.
64
65
------------------------------------------------------------------------
66
67
2.2. When I try to build Valgrind, 'make' fails with /usr/bin/ld: cannot
68
find -lc collect2: ld returned 1 exit status
69
70
You need to install the glibc-static-devel package.
71
62
72
63
73
------------------------------------------------------------------------
64
74
3. Valgrind aborts unexpectedly
65
75
------------------------------------------------------------------------
66
76
67
77
3.1. Programs run OK on Valgrind, but at exit produce a bunch of errors
68
involving __libc_freeres() and then die with a segmentation fault.
78
involving __libc_freeres() and then die with a segmentation fault.
69
79
70
80
When the program exits, Valgrind runs the procedure __libc_freeres() in
71
glibc. This is a hook for memory debuggers, so they can ask glibc to
72
free up any memory it has used. Doing that is needed to ensure that
73
Valgrind doesn't incorrectly report space leaks in glibc.
81
glibc. This is a hook for memory debuggers, so they can ask glibc to
82
free up any memory it has used. Doing that is needed to ensure that
83
Valgrind doesn't incorrectly report space leaks in glibc.
74
84
75
85
Problem is that running __libc_freeres() in older glibc versions causes
76
this crash.
77
78
WORKAROUND FOR 1.1.X and later versions of Valgrind: use the
79
--run-libc-freeres=no flag. You may then get space leak reports for
80
glibc-allocations (please _don't_ report these to the glibc people,
81
since they are not real leaks), but at least the program runs.
82
83
------------------------------------------------------------------------
84
85
3.2. My (buggy) program dies like this:
86
87
88
% valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed.
89
90
If Memcheck (the memory checker) shows any invalid reads, invalid
91
writes and invalid frees in your program, the above may happen. Reason
92
is that your program may trash Valgrind's low-level memory manager,
93
which then dies with the above assertion, or something like this. The
94
cure is to fix your program so that it doesn't do any illegal memory
95
accesses. The above failure will hopefully go away after that.
96
97
------------------------------------------------------------------------
98
99
3.3. My program dies, printing a message like this along the way:
100
101
102
% disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5
103
104
Older versions did not support some x86 instructions, particularly
105
SSE/SSE2 instructions. Try a newer Valgrind; we now support almost all
106
instructions. If it still happens with newer versions, if the failing
107
instruction is an SSE/SSE2 instruction, you might be able to recompile
108
your program without it by using the flag -march to gcc. Either way,
109
let us know and we'll try to fix it.
110
111
Another possibility is that your program has a bug and erroneously
112
jumps to a non-code address, in which case you'll get a SIGILL signal.
113
Memcheck/Addrcheck may issue a warning just before this happens, but
114
they might not if the jump happens to land in addressable memory.
115
116
------------------------------------------------------------------------
117
118
3.4. I tried running a Java program (or another program that uses a
119
just-in-time compiler) under Valgrind but something went wrong.
120
Does Valgrind handle such programs?
121
122
Valgrind can handle dynamically generated code, so long as none of the
123
generated code is later overwritten by other generated code. If this
86
this crash.
87
88
WORKAROUND FOR 1.1.X and later versions of Valgrind: use the
89
--run-libc-freeres=no flag. You may then get space leak reports for
90
glibc-allocations (please _don't_ report these to the glibc people,
91
since they are not real leaks), but at least the program runs.
92
93
------------------------------------------------------------------------
94
95
3.2. My (buggy) program dies like this:
96
97
% valgrind: vg_malloc2.c:442 (bszW_to_pszW): Assertion 'pszW >= 0' failed.
98
99
If Memcheck (the memory checker) shows any invalid reads, invalid writes
100
and invalid frees in your program, the above may happen. Reason is that
101
your program may trash Valgrind's low-level memory manager, which then
102
dies with the above assertion, or something like this. The cure is to
103
fix your program so that it doesn't do any illegal memory accesses. The
104
above failure will hopefully go away after that.
105
106
------------------------------------------------------------------------
107
108
3.3. My program dies, printing a message like this along the way:
109
110
% disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5
111
112
Older versions did not support some x86 instructions, particularly
113
SSE/SSE2 instructions. Try a newer Valgrind; we now support almost all
114
instructions. If it still happens with newer versions, if the failing
115
instruction is an SSE/SSE2 instruction, you might be able to recompile
116
your program without it by using the flag -march to gcc. Either way, let
117
us know and we'll try to fix it.
118
119
Another possibility is that your program has a bug and erroneously jumps
120
to a non-code address, in which case you'll get a SIGILL signal.
121
Memcheck may issue a warning just before this happens, but they might
122
not if the jump happens to land in addressable memory.
123
124
------------------------------------------------------------------------
125
126
3.4. I tried running a Java program (or another program that uses a
127
just-in-time compiler) under Valgrind but something went wrong. Does
128
Valgrind handle such programs?
129
130
Valgrind can handle dynamically generated code, so long as none of the
131
generated code is later overwritten by other generated code. If this
124
132
happens, though, things will go wrong as Valgrind will continue running
125
its translations of the old code (this is true on x86 and AMD64, on
126
PPC32 there are explicit cache flush instructions which Valgrind
127
detects). You should try running with --smc-check=all in this case;
128
Valgrind will run much more slowly, but should detect the use of the
129
out-of-date code.
133
its translations of the old code (this is true on x86 and AMD64, on
134
PPC32 there are explicit cache flush instructions which Valgrind
135
detects). You should try running with --smc-check=all in this case;
136
Valgrind will run much more slowly, but should detect the use of the
137
out-of-date code.
130
138
131
Alternativaly, if you have the source code to the JIT compiler you can
132
insert calls to the VALGRIND_DISCARD_TRANSLATIONS client request to
133
mark out-of-date code, saving you from using --smc-check=all.
139
Alternativaly, if you have the source code to the JIT compiler you can
140
insert calls to the VALGRIND_DISCARD_TRANSLATIONS client request to mark
141
out-of-date code, saving you from using --smc-check=all.
134
142
135
143
Apart from this, in theory Valgrind can run any Java program just fine,
136
even those that use JNI and are partially implemented in other
137
languages like C and C++. In practice, Java implementations tend to do
138
nasty things that most programs do not, and Valgrind sometimes falls
139
over these corner cases.
140
141
If your Java programs do not run under Valgrind, even with
142
--smc-check=all, please file a bug report and hopefully we'll be able
143
to fix the problem.
144
even those that use JNI and are partially implemented in other languages
145
like C and C++. In practice, Java implementations tend to do nasty
146
things that most programs do not, and Valgrind sometimes falls over
147
these corner cases.
148
149
If your Java programs do not run under Valgrind, even with
150
--smc-check=all, please file a bug report and hopefully we'll be able to
151
fix the problem.
152
144
153
145
154
------------------------------------------------------------------------
146
155
4. Valgrind behaves unexpectedly
147
156
------------------------------------------------------------------------
148
157
149
4.1. My program uses the C++ STL and string classes. Valgrind reports
150
'still reachable' memory leaks involving these classes at the exit
151
of the program, but there should be none.
158
4.1. My program uses the C++ STL and string classes. Valgrind reports
159
'still reachable' memory leaks involving these classes at the exit of
160
the program, but there should be none.
152
161
153
First of all: relax, it's probably not a bug, but a feature. Many
162
First of all: relax, it's probably not a bug, but a feature. Many
154
163
implementations of the C++ standard libraries use their own memory pool
155
allocators. Memory for quite a number of destructed objects is not
164
allocators. Memory for quite a number of destructed objects is not
156
165
immediately freed and given back to the OS, but kept in the pool(s) for
157
later re-use. The fact that the pools are not freed at the exit() of
158
the program cause Valgrind to report this memory as still reachable.
159
The behaviour not to free pools at the exit() could be called a bug of
160
the library though.
166
later re-use. The fact that the pools are not freed at the exit() of the
167
program cause Valgrind to report this memory as still reachable. The
168
behaviour not to free pools at the exit() could be called a bug of the
169
library though.
161
170
162
Using gcc, you can force the STL to use malloc and to free memory as
171
Using gcc, you can force the STL to use malloc and to free memory as
163
172
soon as possible by globally disabling memory caching. Beware! Doing so
164
will probably slow down your program, sometimes drastically.
165
166
* With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL
167
with -D__USE_MALLOC. Beware! This is removed from gcc starting with
168
version 3.3.
169
170
* With gcc 3.2.2 and later, you should export the environment variable
171
GLIBCPP_FORCE_NEW before running your program.
172
173
* With gcc 3.4 and later, that variable has changed name to
174
GLIBCXX_FORCE_NEW.
175
176
There are other ways to disable memory pooling: using the malloc_alloc
177
template with your objects (not portable, but should work for gcc) or
178
even writing your own memory allocators. But all this goes beyond the
179
scope of this FAQ. Start by reading
180
<http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3> if you
181
absolutely want to do that. But beware:
182
183
1. there are currently changes underway for gcc which are not totally
184
reflected in the docs right now ("now" == 26 Apr 03)
173
will probably slow down your program, sometimes drastically.
174
175
* With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL
176
with -D__USE_MALLOC. Beware! This is removed from gcc starting with
177
version 3.3.
178
179
* With gcc 3.2.2 and later, you should export the environment variable
180
GLIBCPP_FORCE_NEW before running your program.
181
182
* With gcc 3.4 and later, that variable has changed name to
183
GLIBCXX_FORCE_NEW.
184
185
There are other ways to disable memory pooling: using the malloc_alloc
186
template with your objects (not portable, but should work for gcc) or
187
even writing your own memory allocators. But all this goes beyond the
188
scope of this FAQ. Start by reading
189
http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3:
190
<http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3> if you
191
absolutely want to do that. But beware:
192
193
1. there are currently changes underway for gcc which are not totally
194
reflected in the docs right now ("now" == 26 Apr 03)
185
195
186
196
2. allocators belong to the more messy parts of the STL and people went
187
to great lengths to make it portable across platforms. Chances are
188
good that your solution will work on your platform, but not on
189
others.
197
to great lengths to make it portable across platforms. Chances are good
198
that your solution will work on your platform, but not on others.
190
199
191
200
------------------------------------------------------------------------
192
201
193
4.2. The stack traces given by Memcheck (or another tool) aren't
194
helpful. How can I improve them?
195
196
If they're not long enough, use --num-callers to make them longer.
197
198
If they're not detailed enough, make sure you are compiling with -g to
199
add debug information. And don't strip symbol tables (programs should
200
be unstripped unless you run 'strip' on them; some libraries ship
201
stripped).
202
203
Also, for leak reports involving shared objects, if the shared object
204
is unloaded before the program terminates, Valgrind will discard the
205
debug information and the error message will be full of ??? entries.
206
The workaround here is to avoid calling dlclose() on these shared
207
objects.
208
209
Also, -fomit-frame-pointer and -fstack-check can make stack traces
210
worse.
211
212
Some example sub-traces:
213
214
* With debug information and unstripped (best):
215
202
4.2. The stack traces given by Memcheck (or another tool) aren't
203
helpful. How can I improve them?
204
205
If they're not long enough, use --num-callers to make them longer.
206
207
If they're not detailed enough, make sure you are compiling with -g to
208
add debug information. And don't strip symbol tables (programs should be
209
unstripped unless you run 'strip' on them; some libraries ship
210
stripped).
211
212
Also, for leak reports involving shared objects, if the shared object is
213
unloaded before the program terminates, Valgrind will discard the debug
214
information and the error message will be full of ??? entries. The
215
workaround here is to avoid calling dlclose() on these shared objects.
216
217
Also, -fomit-frame-pointer and -fstack-check can make stack traces
218
worse.
219
220
Some example sub-traces:
221
222
* With debug information and unstripped (best):
223
216
224
Invalid write of size 1
217
225
at 0x80483BF: really (malloc1.c:20)
218
226
by 0x8048370: main (malloc1.c:9)
227
228
* With no debug information, unstripped:
219
229
220
* With no debug information, unstripped:
221
222
230
Invalid write of size 1
223
231
at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out)
224
232
by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out)
233
234
* With no debug information, stripped:
225
235
226
* With no debug information, stripped:
227
228
236
Invalid write of size 1
229
237
at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out)
230
238
by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out)
231
239
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
232
240
by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out)
241
242
* With debug information and -fomit-frame-pointer:
233
243
234
* With debug information and -fomit-frame-pointer:
235
236
244
Invalid write of size 1
237
245
at 0x80483C4: really (malloc1.c:20)
238
246
by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so)
239
247
by 0x80482CC: ??? (start.S:81)
248
249
* A leak error message involving an unloaded shared object:
240
250
241
* A leak error message involving an unloaded shared object:
242
243
251
84 bytes in 1 blocks are possibly lost in loss record 488 of 713
244
252
at 0x1B9036DA: operator new(unsigned) (vg_replace_malloc.c:132)
245
253
by 0x1DB63EEB: ???
246
254
by 0x1DB4B800: ???
247
255
by 0x1D65E007: ???
248
256
by 0x8049EE6: main (main.cpp:24)
249
257
250
258
------------------------------------------------------------------------
251
259
252
4.3. The stack traces given by Memcheck (or another tool) seem to have
253
the wrong function name in them. What's happening?
254
255
Occasionally Valgrind stack traces get the wrong function names. This
256
is caused by glibc using aliases to effectively give one function two
257
names. Most of the time Valgrind chooses a suitable name, but very
258
occasionally it gets it wrong. Examples we know of are printing 'bcmp'
259
instead of 'memcmp', 'index' instead of 'strchr', and 'rindex' instead
260
of 'strrchr'.
260
4.3. The stack traces given by Memcheck (or another tool) seem to have
261
the wrong function name in them. What's happening?
262
263
Occasionally Valgrind stack traces get the wrong function names. This is
264
caused by glibc using aliases to effectively give one function two
265
names. Most of the time Valgrind chooses a suitable name, but very
266
occasionally it gets it wrong. Examples we know of are printing 'bcmp'
267
instead of 'memcmp', 'index' instead of 'strchr', and 'rindex' instead
268
of 'strrchr'.
269
261
270
262
271
------------------------------------------------------------------------
263
272
5. Memcheck doesn't find my bug
264
273
------------------------------------------------------------------------
265
274
266
5.1. I try running "valgrind --tool=memcheck my_program" and get
267
Valgrind's startup message, but I don't get any errors and I know
268
my program has errors.
269
270
There are two possible causes of this.
271
272
First, by default, Valgrind only traces the top-level process. So if
273
your program spawns children, they won't be traced by Valgrind by
274
default. Also, if your program is started by a shell script, Perl
275
script, or something similar, Valgrind will trace the shell, or the
276
Perl interpreter, or equivalent.
277
278
To trace child processes, use the --trace-children=yes option.
279
280
If you are tracing large trees of processes, it can be less disruptive
281
to have the output sent over the network. Give Valgrind the flag
282
--log-socket=127.0.0.1:12345 (if you want logging output sent to port
283
12345 on localhost). You can use the valgrind-listener program to
284
listen on that port:
285
286
287
valgrind-listener 12345
288
289
Obviously you have to start the listener process first. See the manual
290
for more details.
275
5.1. I try running "valgrind --tool=memcheck my_program" and get
276
Valgrind's startup message, but I don't get any errors and I know my
277
program has errors.
278
279
There are two possible causes of this.
280
281
First, by default, Valgrind only traces the top-level process. So if
282
your program spawns children, they won't be traced by Valgrind by
283
default. Also, if your program is started by a shell script, Perl
284
script, or something similar, Valgrind will trace the shell, or the Perl
285
interpreter, or equivalent.
286
287
To trace child processes, use the --trace-children=yes option.
288
289
If you are tracing large trees of processes, it can be less disruptive
290
to have the output sent over the network. Give Valgrind the flag
291
--log-socket=127.0.0.1:12345 (if you want logging output sent to port
292
12345 on localhost). You can use the valgrind-listener program to listen
293
on that port:
294
295
valgrind-listener 12345
296
297
Obviously you have to start the listener process first. See the manual
298
for more details.
291
299
292
300
Second, if your program is statically linked, most Valgrind tools won't
293
work as well, because they won't be able to replace certain functions,
294
such as malloc(), with their own versions. A key indicator of this is
295
if Memcheck says:
296
297
No malloc'd blocks -- no leaks are possible
298
299
when you know your program calls malloc(). The workaround is to avoid
300
statically linking your program.
301
work as well, because they won't be able to replace certain functions,
302
such as malloc(), with their own versions. A key indicator of this is if
303
Memcheck says: All heap blocks were freed -- no leaks are possible when
304
you know your program calls malloc(). The workaround is to avoid
305
statically linking your program.
301
306
302
307
------------------------------------------------------------------------
303
308
304
5.2. Why doesn't Memcheck find the array overruns in this program?
305
306
307
int static[5];
308
309
int main(void)
310
{
311
int stack[5];
312
313
static[5] = 0;
314
stack [5] = 0;
315
316
return 0;
317
}
318
319
Unfortunately, Memcheck doesn't do bounds checking on static or stack
320
arrays. We'd like to, but it's just not possible to do in a reasonable
321
way that fits with how Memcheck works. Sorry.
309
5.2. Why doesn't Memcheck find the array overruns in this program?
310
311
int static[5];
312
313
int main(void)
314
{
315
int stack[5];
316
317
static[5] = 0;
318
stack [5] = 0;
319
320
return 0;
321
}
322
323
Unfortunately, Memcheck doesn't do bounds checking on static or stack
324
arrays. We'd like to, but it's just not possible to do in a reasonable
325
way that fits with how Memcheck works. Sorry.
326
322
327
323
328
------------------------------------------------------------------------
324
329
6. Miscellaneous
325
330
------------------------------------------------------------------------
326
331
327
332
6.1. I tried writing a suppression but it didn't work. Can you write my
328
suppression for me?
329
330
Yes! Use the --gen-suppressions=yes feature to spit out suppressions
331
automatically for you. You can then edit them if you like, eg.
332
combining similar automatically generated suppressions using wildcards
333
like '*'.
334
335
If you really want to write suppressions by hand, read the manual
333
suppression for me?
334
335
Yes! Use the --gen-suppressions=yes feature to spit out suppressions
336
automatically for you. You can then edit them if you like, eg. combining
337
similar automatically generated suppressions using wildcards like '*'.
338
339
If you really want to write suppressions by hand, read the manual
336
340
carefully. Note particularly that C++ function names must be _mangled_.
337
341
338
342
------------------------------------------------------------------------
339
343
340
6.2. With Memcheck/Addrcheck's memory leak detector, what's the
341
difference between "definitely lost", "possibly lost", "still
342
reachable", and "suppressed"?
343
344
The details are in the Memcheck section of the user manual.
345
346
In short:
347
348
* "definitely lost" means your program is leaking memory -- fix it!
344
6.2. With Memcheck's memory leak detector, what's the difference between
345
"definitely lost", "possibly lost", "still reachable", and "suppressed"?
346
347
The details are in the Memcheck section of the user manual.
348
349
In short:
350
351
* "definitely lost" means your program is leaking memory -- fix it!
349
352
350
353
* "possibly lost" means your program is probably leaking memory, unless
351
you're doing funny things with pointers.
354
you're doing funny things with pointers.
352
355
353
356
* "still reachable" means your program is probably ok -- it didn't free
354
some memory it could have. This is quite common and often reasonable.
355
Don't use --show-reachable=yes if you don't want to see these reports.
356
357
* "suppressed" means that a leak error has been suppressed. There are
358
some suppressions in the default suppression files. You can ignore
359
suppressed errors.
357
some memory it could have. This is quite common and often reasonable.
358
Don't use --show-reachable=yes if you don't want to see these reports.
359
360
* "suppressed" means that a leak error has been suppressed. There are
361
some suppressions in the default suppression files. You can ignore
362
suppressed errors.
363
360
364
361
365
------------------------------------------------------------------------
362
366
7. How To Get Further Assistance
363
367
------------------------------------------------------------------------
364
368
365
Please read all of this section before posting.
366
367
If you think an answer is incomplete or inaccurate, please e-mail
368
'valgrind@valgrind.org' <mailto:valgrind@valgrind.org>.
369
370
Read the appropriate section(s) of the Manual(s): 'Valgrind
371
Documentation' <http://www.valgrind.org/docs/>.
372
373
Read the 'Distribution Documents' <http://www.valgrind.org/docs/>.
374
375
'Search' <http://search.gmane.org> the 'valgrind-users'
376
<http://news.gmane.org/gmane.comp.debugging.valgrind> mailing list
377
archives, using the group name gmane.comp.debugging.valgrind.
378
379
Only when you have tried all of these things and are still stuck,
380
should you post to the 'valgrind-users mailing list'
381
<http://lists.sourceforge.net/lists/listinfo/valgrind-users>. In which
382
case, please read the following carefully. Making a complete posting
369
Please read all of this section before posting.
370
371
If you think an answer is incomplete or inaccurate, please e-mail
372
valgrind@valgrind.org: <valgrind@valgrind.org>.
373
374
Read the appropriate section(s) of the Valgrind Documentation:
375
<http://www.valgrind.org/docs/manual/index.html>.
376
377
Read the Distribution Documents:
378
<http://www.valgrind.org/docs/manual/dist.html>.
379
380
Search: <http://search.gmane.org> the valgrind-users:
381
<http://news.gmane.org/gmane.comp.debugging.valgrind> mailing list
382
archives, using the group name gmane.comp.debugging.valgrind.
383
384
Only when you have tried all of these things and are still stuck, should
385
you post to the valgrind-users mailing list:
386
<http://lists.sourceforge.net/lists/listinfo/valgrind-users>. In which
387
case, please read the following carefully. Making a complete posting
383
388
will greatly increase the chances that an expert or fellow user reading
384
it will have enough information and motivation to reply.
385
386
Make sure you give full details of the problem, including the full
387
output of valgrind -v, if applicable. Also which Linux distribution
388
you're using (Red Hat, Debian, etc) and its version number.
389
390
You are in little danger of making your posting too long unless you
391
include large chunks of valgrind's (unsuppressed) output, so err on the
392
side of giving too much information.
393
394
Clearly written subject lines and message bodies are appreciated, too.
389
it will have enough information and motivation to reply.
390
391
Make sure you give full details of the problem, including the full
392
output of valgrind -v <your-prog>, if applicable. Also which Linux
393
distribution you're using (Red Hat, Debian, etc) and its version number.
394
395
You are in little danger of making your posting too long unless you
396
include large chunks of Valgrind's (unsuppressed) output, so err on the
397
side of giving too much information.
398
399
Clearly written subject lines and message bodies are appreciated, too.
395
400
396
401
Finally, remember that, despite the fact that most of the community are
397
very helpful and responsive to emailed questions, you are probably
398
requesting help from unpaid volunteers, so you have no guarantee of
399
receiving an answer.
402
very helpful and responsive to emailed questions, you are probably
403
requesting help from unpaid volunteers, so you have no guarantee of
404
receiving an answer.
400
405
Loggerhead is a web-based interface for Breezy
Version: 2.0.1