1VALGRIND(1) Release 3.5.0 VALGRIND(1)
2
6 valgrind - a suite of tools for debugging and profiling programs
7
9 valgrind [valgrind-options] [your-program] [your-program-options]
10
12 Valgrind is a flexible program for debugging and profiling Linux
13 executables. It consists of a core, which provides a synthetic CPU in
14 software, and a series of debugging and profiling tools. The
15 architecture is modular, so that new tools can be created easily and
16 without disturbing the existing structure.
17 Some of the options described below work with all Valgrind tools, and
19 some only work with a few or one. The section MEMCHECK OPTIONS and
20 those below it describe tool-specific options.
21 This manual page covers only basic usage and options. For more
23 comprehensive information, please see the HTML documentation on your
24 system: $INSTALL/share/doc/valgrind/html/index.html, or online:
25 http://www.valgrind.org/docs/manual/index.html.
26
28 These options work with all tools.
29 -h --help
31 Show help for all options, both for the core and for the
32 selected tool.
33 --help-debug
35 Same as --help, but also lists debugging options which usually
36 are only of use to Valgrind's developers.
37 --version
39 Show the version number of the Valgrind core. Tools can have
40 their own version numbers. There is a scheme in place to ensure
41 that tools only execute when the core version is one they are
42 known to work with. This was done to minimise the chances of
43 strange problems arising from tool-vs-core version
44 incompatibilities.
45 -q, --quiet
47 Run silently, and only print error messages. Useful if you are
48 running regression tests or have some other automated test
49 machinery.
50 -v, --verbose
52 Be more verbose. Gives extra information on various aspects of
53 your program, such as: the shared objects loaded, the
54 suppressions used, the progress of the instrumentation and
55 execution engines, and warnings about unusual behaviour.
56 Repeating the option increases the verbosity level.
57 --trace-children=<yes|no> [default: no]
59 When enabled, Valgrind will trace into sub-processes initiated
60 via the exec system call. This is necessary for multi-process
61 programs.
62 Note that Valgrind does trace into the child of a fork (it would
64 be difficult not to, since fork makes an identical copy of a
65 process), so this option is arguably badly named. However, most
66 children of fork calls immediately call exec anyway.
67 --child-silent-after-fork=<yes|no> [default: no]
69 When enabled, Valgrind will not show any debugging or logging
70 output for the child process resulting from a fork call. This
71 can make the output less confusing (although more misleading)
72 when dealing with processes that create children. It is
73 particularly useful in conjunction with --trace-children=. Use
74 of this option is also strongly recommended if you are
75 requesting XML output (--xml=yes), since otherwise the XML from
76 child and parent may become mixed up, which usually makes it
77 useless.
78 --track-fds=<yes|no> [default: no]
80 When enabled, Valgrind will print out a list of open file
81 descriptors on exit. Along with each file descriptor is printed
82 a stack backtrace of where the file was opened and any details
83 relating to the file descriptor such as the file name or socket
84 details.
85 --time-stamp=<yes|no> [default: no]
87 When enabled, each message is preceded with an indication of the
88 elapsed wallclock time since startup, expressed as days, hours,
89 minutes, seconds and milliseconds.
90 --log-fd=<number> [default: 2, stderr]
92 Specifies that Valgrind should send all of its messages to the
93 specified file descriptor. The default, 2, is the standard error
94 channel (stderr). Note that this may interfere with the client's
95 own use of stderr, as Valgrind's output will be interleaved with
96 any output that the client sends to stderr.
97 --log-file=<filename>
99 Specifies that Valgrind should send all of its messages to the
100 specified file. If the file name is empty, it causes an abort.
101 There are three special format specifiers that can be used in
102 the file name.
103 %p is replaced with the current process ID. This is very useful
105 for program that invoke multiple processes. WARNING: If you use
106 --trace-children=yes and your program invokes multiple processes
107 OR your program forks without calling exec afterwards, and you
108 don't use this specifier (or the %q specifier below), the
109 Valgrind output from all those processes will go into one file,
110 possibly jumbled up, and possibly incomplete.
111 %q{FOO} is replaced with the contents of the environment
113 variable FOO. If the {FOO} part is malformed, it causes an
114 abort. This specifier is rarely needed, but very useful in
115 certain circumstances (eg. when running MPI programs). The idea
116 is that you specify a variable which will be set differently for
117 each process in the job, for example BPROC_RANK or whatever is
118 applicable in your MPI setup. If the named environment variable
119 is not set, it causes an abort. Note that in some shells, the {
120 and } characters may need to be escaped with a backslash.
121 %% is replaced with %.
123 If an % is followed by any other character, it causes an abort.
125 --log-socket=<ip-address:port-number>
127 Specifies that Valgrind should send all of its messages to the
128 specified port at the specified IP address. The port may be
129 omitted, in which case port 1500 is used. If a connection cannot
130 be made to the specified socket, Valgrind falls back to writing
131 output to the standard error (stderr). This option is intended
132 to be used in conjunction with the valgrind-listener program.
133 For further details, see the commentary in the manual.
134
136 These options are used by all tools that can report errors, e.g.
137 Memcheck, but not Cachegrind.
138 --xml=<yes|no> [default: no]
140 When enabled, the important parts of the output (e.g. tool error
141 messages) will be in XML format rather than plain text.
142 Furthermore, the XML output will be sent to a different output
143 channel than the plain text output. Therefore, you also must use
144 one of --xml-fd, --xml-file or --xml-socket to specify where the
145 XML is to be sent.
146 Less important messages will still be printed in plain text, but
148 because the XML output and plain text output are sent to
149 different output channels (the destination of the plain text
150 output is still controlled by --log-fd, --log-file and
151 --log-socket) this should not cause problems.
152 This option is aimed at making life easier for tools that
154 consume Valgrind's output as input, such as GUI front ends.
155 Currently this option works with Memcheck, Helgrind and
156 Ptrcheck. The output format is specified in the file
157 docs/internals/xml-output-protocol4.txt in the source tree for
158 Valgrind 3.5.0 or later.
159 The recommended options for a GUI to pass, when requesting XML
161 output, are: --xml=yes to enable XML output, --xml-file to send
162 the XML output to a (presumably GUI-selected) file, --log-file
163 to send the plain text output to a second GUI-selected file,
164 --child-silent-after-fork=yes, and -q to restrict the plain text
165 output to critical error messages created by Valgrind itself.
166 For example, failure to read a specified suppressions file
167 counts as a critical error message. In this way, for a
168 successful run the text output file will be empty. But if it
169 isn't empty, then it will contain important information which
170 the GUI user should be made aware of.
171 --xml-fd=<number> [default: -1, disabled]
173 Specifies that Valgrind should send its XML output to the
174 specified file descriptor. It must be used in conjunction with
175 --xml=yes.
176 --xml-file=<filename>
178 Specifies that Valgrind should send its XML output to the
179 specified file. It must be used in conjunction with --xml=yes.
180 Any %p or %q sequences appearing in the filename are expanded in
181 exactly the same way as they are for --log-file. See the
182 description of --log-file for details.
183 --xml-socket=<ip-address:port-number>
185 Specifies that Valgrind should send its XML output the specified
186 port at the specified IP address. It must be used in conjunction
187 with --xml=yes. The form of the argument is the same as that
188 used by --log-socket. See the description of --log-socket for
189 further details.
190 --xml-user-comment=<string>
192 Embeds an extra user comment string at the start of the XML
193 output. Only works when --xml=yes is specified; ignored
194 otherwise.
195 --demangle=<yes|no> [default: yes]
197 Enable/disable automatic demangling (decoding) of C++ names.
198 Enabled by default. When enabled, Valgrind will attempt to
199 translate encoded C++ names back to something approaching the
200 original. The demangler handles symbols mangled by g++ versions
201 2.X, 3.X and 4.X.
202 An important fact about demangling is that function names
204 mentioned in suppressions files should be in their mangled form.
205 Valgrind does not demangle function names when searching for
206 applicable suppressions, because to do otherwise would make
207 suppression file contents dependent on the state of Valgrind's
208 demangling machinery, and also slow down suppression matching.
209 --num-callers=<number> [default: 12]
211 Specifies the maximum number of entries shown in stack traces
212 that identify program locations. Note that errors are commoned
213 up using only the top four function locations (the place in the
214 current function, and that of its three immediate callers). So
215 this doesn't affect the total number of errors reported.
216 The maximum value for this is 50. Note that higher settings will
218 make Valgrind run a bit more slowly and take a bit more memory,
219 but can be useful when working with programs with deeply-nested
220 call chains.
221 --error-limit=<yes|no> [default: yes]
223 When enabled, Valgrind stops reporting errors after 10,000,000
224 in total, or 1,000 different ones, have been seen. This is to
225 stop the error tracking machinery from becoming a huge
226 performance overhead in programs with many errors.
227 --error-exitcode=<number> [default: 0]
229 Specifies an alternative exit code to return if Valgrind
230 reported any errors in the run. When set to the default value
231 (zero), the return value from Valgrind will always be the return
232 value of the process being simulated. When set to a nonzero
233 value, that value is returned instead, if Valgrind detects any
234 errors. This is useful for using Valgrind as part of an
235 automated test suite, since it makes it easy to detect test
236 cases for which Valgrind has reported errors, just by inspecting
237 return codes.
238 --show-below-main=<yes|no> [default: no]
240 By default, stack traces for errors do not show any functions
241 that appear beneath main because most of the time it's
242 uninteresting C library stuff and/or gobbledygook.
243 Alternatively, if main is not present in the stack trace, stack
244 traces will not show any functions below main-like functions
245 such as glibc's __libc_start_main. Furthermore, if main-like
246 functions are present in the trace, they are normalised as
247 (below main), in order to make the output more deterministic.
248 If this option is enabled, all stack trace entries will be shown
250 and main-like functions will not be normalised.
251 --suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]
253 Specifies an extra file from which to read descriptions of
254 errors to suppress. You may use up to 100 extra suppression
255 files.
256 --gen-suppressions=<yes|no|all> [default: no]
258 When set to yes, Valgrind will pause after every error shown and
259 print the line:
260 ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
262 The prompt's behaviour is the same as for the --db-attach option
264 (see below).
265 If you choose to, Valgrind will print out a suppression for this
267 error. You can then cut and paste it into a suppression file if
268 you don't want to hear about the error in the future.
269 When set to all, Valgrind will print a suppression for every
271 reported error, without querying the user.
272 This option is particularly useful with C++ programs, as it
274 prints out the suppressions with mangled names, as required.
275 Note that the suppressions printed are as specific as possible.
277 You may want to common up similar ones, by adding wildcards to
278 function names, and by using frame-level wildcards. The
279 wildcarding facilities are powerful yet flexible, and with a bit
280 of careful editing, you may be able to suppress a whole family
281 of related errors with only a few suppressions.
282 Sometimes two different errors are suppressed by the same
284 suppression, in which case Valgrind will output the suppression
285 more than once, but you only need to have one copy in your
286 suppression file (but having more than one won't cause
287 problems). Also, the suppression name is given as <insert a
288 suppression name here>; the name doesn't really matter, it's
289 only used with the -v option which prints out all used
290 suppression records.
291 --db-attach=<yes|no> [default: no]
293 When enabled, Valgrind will pause after every error shown and
294 print the line:
295 ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----
297 Pressing Ret, or N Ret or n Ret, causes Valgrind not to start a
299 debugger for this error.
300 Pressing Y Ret or y Ret causes Valgrind to start a debugger for
302 the program at this point. When you have finished with the
303 debugger, quit from it, and the program will continue. Trying to
304 continue from inside the debugger doesn't work.
305 C Ret or c Ret causes Valgrind not to start a debugger, and not
307 to ask again.
308 --db-command=<command> [default: gdb -nw %f %p]
310 Specify the debugger to use with the --db-attach command. The
311 default debugger is GDB. This option is a template that is
312 expanded by Valgrind at runtime. %f is replaced with the
313 executable's file name and %p is replaced by the process ID of
314 the executable.
315 This specifies how Valgrind will invoke the debugger. By default
317 it will use whatever GDB is detected at build time, which is
318 usually /usr/bin/gdb. Using this command, you can specify some
319 alternative command to invoke the debugger you want to use.
320 The command string given can include one or instances of the %p
322 and %f expansions. Each instance of %p expands to the PID of the
323 process to be debugged and each instance of %f expands to the
324 path to the executable for the process to be debugged.
325 Since <command> is likely to contain spaces, you will need to
327 put this entire option in quotes to ensure it is correctly
328 handled by the shell.
329 --input-fd=<number> [default: 0, stdin]
331 When using --db-attach=yes or --gen-suppressions=yes, Valgrind
332 will stop so as to read keyboard input from you when each error
333 occurs. By default it reads from the standard input (stdin),
334 which is problematic for programs which close stdin. This option
335 allows you to specify an alternative file descriptor from which
336 to read input.
337 --dsymutil=no|yes [no]
339 This option is only relevant when running Valgrind on Mac OS X.
340 Mac OS X uses a deferred debug information (debuginfo) linking
342 scheme. When object files containing debuginfo are linked into a
343 or an executable, the debuginfo is not copied into the final
344 file. Instead, the debuginfo must be linked manually by running
345 dsymutil, a system-provided utility, on the executable or
346 With --dsymutil=no, Valgrind will detect cases where the
348 directory is either missing, or is present but does not appear
349 to match the associated executable or
350 With --dsymutil=yes, Valgrind will, in such cases, automatically
352 run dsymutil as necessary to bring the debuginfo up to date. For
353 all practical purposes, if you always use --dsymutil=yes, then
354 there is never any need to run dsymutil manually or as part of
355 your applications's build system, since Valgrind will run it as
356 necessary.
357 Valgrind will not attempt to run dsymutil on any executable or
359 library in /usr/, /bin/, /sbin/, /opt/, /sw/, /System/,
360 /Library/ or /Applications/ since dsymutil will always fail in
361 such situations. It fails both because the debuginfo for such
362 pre-installed system components is not available anywhere, and
363 also because it would require write privileges in those
364 directories.
365 Be careful when using --dsymutil=yes, since it will cause
367 pre-existing directories to be silently deleted and re-created.
368 Also note the dsymutil is quite slow, sometimes excessively so.
369 --max-stackframe=<number> [default: 2000000]
371 The maximum size of a stack frame. If the stack pointer moves by
372 more than this amount then Valgrind will assume that the program
373 is switching to a different stack.
374 You may need to use this option if your program has large
376 stack-allocated arrays. Valgrind keeps track of your program's
377 stack pointer. If it changes by more than the threshold amount,
378 Valgrind assumes your program is switching to a different stack,
379 and Memcheck behaves differently than it would for a stack
380 pointer change smaller than the threshold. Usually this
381 heuristic works well. However, if your program allocates large
382 structures on the stack, this heuristic will be fooled, and
383 Memcheck will subsequently report large numbers of invalid stack
384 accesses. This option allows you to change the threshold to a
385 different value.
386 You should only consider use of this option if Valgrind's debug
388 output directs you to do so. In that case it will tell you the
389 new threshold you should specify.
390 In general, allocating large structures on the stack is a bad
392 idea, because you can easily run out of stack space, especially
393 on systems with limited memory or which expect to support large
394 numbers of threads each with a small stack, and also because the
395 error checking performed by Memcheck is more effective for
396 heap-allocated data than for stack-allocated data. If you have
397 to use this option, you may wish to consider rewriting your code
398 to allocate on the heap rather than on the stack.
399 --main-stacksize=<number> [default: use current 'ulimit' value]
401 Specifies the size of the main thread's stack.
402 To simplify its memory management, Valgrind reserves all
404 required space for the main thread's stack at startup. That
405 means it needs to know the required stack size at startup.
406 By default, Valgrind uses the current "ulimit" value for the
408 stack size, or 16 MB, whichever is lower. In many cases this
409 gives a stack size in the range 8 to 16 MB, which almost never
410 overflows for most applications.
411 If you need a larger total stack size, use --main-stacksize to
413 specify it. Only set it as high as you need, since reserving far
414 more space than you need (that is, hundreds of megabytes more
415 than you need) constrains Valgrind's memory allocators and may
416 reduce the total amount of memory that Valgrind can use. This is
417 only really of significance on 32-bit machines.
418 On Linux, you may request a stack of size up to 2GB. Valgrind
420 will stop with a diagnostic message if the stack cannot be
421 allocated. On AIX5 the allowed stack size is restricted to
422 128MB.
423 --main-stacksize only affects the stack size for the program's
425 initial thread. It has no bearing on the size of thread stacks,
426 as Valgrind does not allocate those.
427 You may need to use both --main-stacksize and --max-stackframe
429 together. It is important to understand that --main-stacksize
430 sets the maximum total stack size, whilst --max-stackframe
431 specifies the largest size of any one stack frame. You will have
432 to work out the --main-stacksize value for yourself (usually, if
433 your applications segfaults). But Valgrind will tell you the
434 needed --max-stackframe size, if necessary.
435 As discussed further in the description of --max-stackframe, a
437 requirement for a large stack is a sign of potential portability
438 problems. You are best advised to place all large data in
439 heap-allocated memory.
440
442 For tools that use their own version of malloc (e.g. Memcheck and
443 Massif), the following options apply.
444 --alignment=<number> [default: 8 or 16, depending on the platform]
446 By default Valgrind's malloc, realloc, etc, return a block whose
447 starting address is 8-byte aligned or 16-byte aligned (the value
448 depends on the platform and matches the platform default). This
449 option allows you to specify a different alignment. The supplied
450 value must be greater than or equal to the default, less than or
451 equal to 4096, and must be a power of two.
452
454 These options apply to all tools, as they affect certain obscure
455 workings of the Valgrind core. Most people won't need to use these.
456 --smc-check=<none|stack|all> [default: stack]
458 This option controls Valgrind's detection of self-modifying
459 code. If no checking is done, if a program executes some code,
460 then overwrites it with new code, and executes the new code,
461 Valgrind will continue to execute the translations it made for
462 the old code. This will likely lead to incorrect behaviour
463 and/or crashes.
464 Valgrind has three levels of self-modifying code detection: no
466 detection, detect self-modifying code on the stack (which used
467 by GCC to implement nested functions), or detect self-modifying
468 code everywhere. Note that the default option will catch the
469 vast majority of cases. The main case it will not catch is
470 programs such as JIT compilers that dynamically generate code
471 and subsequently overwrite part or all of it. Running with all
472 will slow Valgrind down greatly. Running with none will rarely
473 speed things up, since very little code gets put on the stack
474 for most programs. The VALGRIND_DISCARD_TRANSLATIONS client
475 request is an alternative to --smc-check=all that requires more
476 effort but is much faster.
477 Some architectures (including ppc32 and ppc64) require programs
479 which create code at runtime to flush the instruction cache in
480 between code generation and first use. Valgrind observes and
481 honours such instructions. Hence, on ppc32/Linux and
482 ppc64/Linux, Valgrind always provides complete, transparent
483 support for self-modifying code. It is only on platforms such as
484 x86/Linux, AMD64/Linux and x86/Darwin that you need to use this
485 option.
486 --read-var-info=<yes|no> [default: no]
488 When enabled, Valgrind will read information about variable
489 types and locations from DWARF3 debug info. This slows Valgrind
490 down and makes it use more memory, but for the tools that can
491 take advantage of it (Memcheck, Helgrind, DRD) it can result in
492 more precise error messages. For example, here are some standard
493 errors issued by Memcheck:
494 ==15516== Uninitialised byte(s) found during client check request
496 ==15516== at 0x400633: croak (varinfo1.c:28)
497 ==15516== by 0x4006B2: main (varinfo1.c:55)
498 ==15516== Address 0x60103b is 7 bytes inside data symbol "global_i2"
499 ==15516==
500 ==15516== Uninitialised byte(s) found during client check request
501 ==15516== at 0x400633: croak (varinfo1.c:28)
502 ==15516== by 0x4006BC: main (varinfo1.c:56)
503 ==15516== Address 0x7fefffefc is on thread 1's stack
504 And here are the same errors with --read-var-info=yes:
505 ==15522== Uninitialised byte(s) found during client check request
507 ==15522== at 0x400633: croak (varinfo1.c:28)
508 ==15522== by 0x4006B2: main (varinfo1.c:55)
509 ==15522== Location 0x60103b is 0 bytes inside global_i2[7],
510 ==15522== a global variable declared at varinfo1.c:41
511 ==15522==
512 ==15522== Uninitialised byte(s) found during client check request
513 ==15522== at 0x400633: croak (varinfo1.c:28)
514 ==15522== by 0x4006BC: main (varinfo1.c:56)
515 ==15522== Location 0x7fefffefc is 0 bytes inside local var "local"
516 ==15522== declared at varinfo1.c:46, in frame #1 of thread 1
517 --run-libc-freeres=<yes|no> [default: yes]
519 This option is only relevant when running Valgrind on Linux.
520 The GNU C library (libc.so), which is used by all programs, may
522 allocate memory for its own uses. Usually it doesn't bother to
523 free that memory when the program ends—there would be no point,
524 since the Linux kernel reclaims all process resources when a
525 process exits anyway, so it would just slow things down.
526 The glibc authors realised that this behaviour causes leak
528 checkers, such as Valgrind, to falsely report leaks in glibc,
529 when a leak check is done at exit. In order to avoid this, they
530 provided a routine called __libc_freeres specifically to make
531 glibc release all memory it has allocated. Memcheck therefore
532 tries to run __libc_freeres at exit.
533 Unfortunately, in some very old versions of glibc,
535 __libc_freeres is sufficiently buggy to cause segmentation
536 faults. This was particularly noticeable on Red Hat 7.1. So this
537 option is provided in order to inhibit the run of
538 __libc_freeres. If your program seems to run fine on Valgrind,
539 but segfaults at exit, you may find that --run-libc-freeres=no
540 fixes that, although at the cost of possibly falsely reporting
541 space leaks in libc.so.
542 --sim-hints=hint1,hint2,...
544 Pass miscellaneous hints to Valgrind which slightly modify the
545 simulated behaviour in nonstandard or dangerous ways, possibly
546 to help the simulation of strange features. By default no hints
547 are enabled. Use with caution! Currently known hints are:
548 · lax-ioctls: Be very lax about ioctl handling; the only
550 assumption is that the size is correct. Doesn't require the
551 full buffer to be initialized when writing. Without this,
552 using some device drivers with a large number of strange
553 ioctl commands becomes very tiresome.
554 · enable-inner: Enable some special magic needed when the
556 program being run is itself Valgrind.
557 --kernel-variant=variant1,variant2,...
559 Handle system calls and ioctls arising from minor variants of
560 the default kernel for this platform. This is useful for running
561 on hacked kernels or with kernel modules which support
562 nonstandard ioctls, for example. Use with caution. If you don't
563 understand what this option does then you almost certainly don't
564 need it. Currently known variants are:
565 · bproc: Support the sys_broc system call on x86. This is for
567 running on BProc, which is a minor variant of standard Linux
568 which is sometimes used for building clusters.
569 --show-emwarns=<yes|no> [default: no]
571 When enabled, Valgrind will emit warnings about its CPU
572 emulation in certain cases. These are usually not interesting.
573
575 There are also some options for debugging Valgrind itself. You
576 shouldn't need to use them in the normal run of things. If you wish to
577 see the list, use the --help-debug option.
578
580 --leak-check=<no|summary|yes|full> [default: summary]
581 When enabled, search for memory leaks when the client program
582 finishes. If set to summary, it says how many leaks occurred. If
583 set to full or yes, it also gives details of each individual
584 leak.
585 --leak-resolution=<low|med|high> [default: high]
587 When doing leak checking, determines how willing Memcheck is to
588 consider different backtraces to be the same for the purposes of
589 merging multiple leaks into a single leak report. When set to
590 low, only the first two entries need match. When med, four
591 entries have to match. When high, all entries need to match.
592 For hardcore leak debugging, you probably want to use
594 --leak-resolution=high together with --num-callers=40 or some
595 such large number.
596 Note that the --leak-resolution setting does not affect
598 Memcheck's ability to find leaks. It only changes how the
599 results are presented.
600 --show-reachable=<yes|no> [default: no]
602 When disabled, the memory leak detector only shows "definitely
603 lost" and "possibly lost" blocks. When enabled, the leak
604 detector also shows "reachable" and "indirectly lost" blocks.
605 (In other words, it shows all blocks, except suppressed ones, so
606 --show-all would be a better name for it.)
607 --undef-value-errors=<yes|no> [default: yes]
609 Controls whether Memcheck reports uses of undefined value
610 errors. Set this to no if you don't want to see undefined value
611 errors. It also has the side effect of speeding up Memcheck
612 somewhat.
613 --track-origins=<yes|no> [default: no]
615 Controls whether Memcheck tracks the origin of uninitialised
616 values. By default, it does not, which means that although it
617 can tell you that an uninitialised value is being used in a
618 dangerous way, it cannot tell you where the uninitialised value
619 came from. This often makes it difficult to track down the root
620 problem.
621 When set to yes, Memcheck keeps track of the origins of all
623 uninitialised values. Then, when an uninitialised value error is
624 reported, Memcheck will try to show the origin of the value. An
625 origin can be one of the following four places: a heap block, a
626 stack allocation, a client request, or miscellaneous other
627 sources (eg, a call to brk).
628 For uninitialised values originating from a heap block, Memcheck
630 shows where the block was allocated. For uninitialised values
631 originating from a stack allocation, Memcheck can tell you which
632 function allocated the value, but no more than that -- typically
633 it shows you the source location of the opening brace of the
634 function. So you should carefully check that all of the
635 function's local variables are initialised properly.
636 Performance overhead: origin tracking is expensive. It halves
638 Memcheck's speed and increases memory use by a minimum of 100MB,
639 and possibly more. Nevertheless it can drastically reduce the
640 effort required to identify the root cause of uninitialised
641 value errors, and so is often a programmer productivity win,
642 despite running more slowly.
643 Accuracy: Memcheck tracks origins quite accurately. To avoid
645 very large space and time overheads, some approximations are
646 made. It is possible, although unlikely, that Memcheck will
647 report an incorrect origin, or not be able to identify any
648 origin.
649 Note that the combination --track-origins=yes and
651 --undef-value-errors=no is nonsensical. Memcheck checks for and
652 rejects this combination at startup.
653 --partial-loads-ok=<yes|no> [default: no]
655 Controls how Memcheck handles word-sized, word-aligned loads
656 from addresses for which some bytes are addressable and others
657 are not. When yes, such loads do not produce an address error.
658 Instead, loaded bytes originating from illegal addresses are
659 marked as uninitialised, and those corresponding to legal
660 addresses are handled in the normal way.
661 When no, loads from partially invalid addresses are treated the
663 same as loads from completely invalid addresses: an
664 illegal-address error is issued, and the resulting bytes are
665 marked as initialised.
666 Note that code that behaves in this way is in violation of the
668 the ISO C/C++ standards, and should be considered broken. If at
669 all possible, such code should be fixed. This option should be
670 used only as a last resort.
671 --freelist-vol=<number> [default: 10000000]
673 When the client program releases memory using free (in C) or
674 delete (C++), that memory is not immediately made available for
675 re-allocation. Instead, it is marked inaccessible and placed in
676 a queue of freed blocks. The purpose is to defer as long as
677 possible the point at which freed-up memory comes back into
678 circulation. This increases the chance that Memcheck will be
679 able to detect invalid accesses to blocks for some significant
680 period of time after they have been freed.
681 This option specifies the maximum total size, in bytes, of the
683 blocks in the queue. The default value is ten million bytes.
684 Increasing this increases the total amount of memory used by
685 Memcheck but may detect invalid uses of freed blocks which would
686 otherwise go undetected.
687 --workaround-gcc296-bugs=<yes|no> [default: no]
689 When enabled, assume that reads and writes some small distance
690 below the stack pointer are due to bugs in GCC 2.96, and does
691 not report them. The "small distance" is 256 bytes by default.
692 Note that GCC 2.96 is the default compiler on some ancient Linux
693 distributions (RedHat 7.X) and so you may need to use this
694 option. Do not use it if you do not have to, as it can cause
695 real errors to be overlooked. A better alternative is to use a
696 more recent GCC in which this bug is fixed.
697 You may also need to use this option when working with GCC 3.X
699 or 4.X on 32-bit PowerPC Linux. This is because GCC generates
700 code which occasionally accesses below the stack pointer,
701 particularly for floating-point to/from integer conversions.
702 This is in violation of the 32-bit PowerPC ELF specification,
703 which makes no provision for locations below the stack pointer
704 to be accessible.
705 --ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
707 Any ranges listed in this option (and multiple ranges can be
708 specified, separated by commas) will be ignored by Memcheck's
709 addressability checking.
710 --malloc-fill=<hexnumber>
712 Fills blocks allocated by malloc, new, etc, but not by calloc,
713 with the specified byte. This can be useful when trying to shake
714 out obscure memory corruption problems. The allocated area is
715 still regarded by Memcheck as undefined -- this option only
716 affects its contents.
717 --free-fill=<hexnumber>
719 Fills blocks freed by free, delete, etc, with the specified byte
720 value. This can be useful when trying to shake out obscure
721 memory corruption problems. The freed area is still regarded by
722 Memcheck as not valid for access -- this option only affects its
723 contents.
724
726 --I1=<size>,<associativity>,<line size>
727 Specify the size, associativity and line size of the level 1
728 instruction cache.
729 --D1=<size>,<associativity>,<line size>
731 Specify the size, associativity and line size of the level 1
732 data cache.
733 --L2=<size>,<associativity>,<line size>
735 Specify the size, associativity and line size of the level 2
736 cache.
737 --cache-sim=no|yes [yes]
739 Enables or disables collection of cache access and miss counts.
740 --branch-sim=no|yes [no]
742 Enables or disables collection of branch instruction and
743 misprediction counts. By default this is disabled as it slows
744 Cachegrind down by approximately 25%. Note that you cannot
745 specify --cache-sim=no and --branch-sim=no together, as that
746 would leave Cachegrind with no information to collect.
747 --cachegrind-out-file=<file>
749 Write the profile data to file rather than to the default output
750 file, cachegrind.out.<pid>. The %p and %q format specifiers can
751 be used to embed the process ID and/or the contents of an
752 environment variable in the name, as is the case for the core
753 option --log-file.
754
756 --callgrind-out-file=<file>
757 Write the profile data to file rather than to the default output
758 file, callgrind.out.<pid>. The %p and %q format specifiers can
759 be used to embed the process ID and/or the contents of an
760 environment variable in the name, as is the case for the core
761 option --log-file. When multiple dumps are made, the file name
762 is modified further; see below.
763 --dump-line=<no|yes> [default: yes]
765 This specifies that event counting should be performed at source
766 line granularity. This allows source annotation for sources
767 which are compiled with debug information (-g).
768 --dump-instr=<no|yes> [default: no]
770 This specifies that event counting should be performed at
771 per-instruction granularity. This allows for assembly code
772 annotation. Currently the results can only be displayed by
773 KCachegrind.
774 --compress-strings=<no|yes> [default: yes]
776 This option influences the output format of the profile data. It
777 specifies whether strings (file and function names) should be
778 identified by numbers. This shrinks the file, but makes it more
779 difficult for humans to read (which is not recommended in any
780 case).
781 --compress-pos=<no|yes> [default: yes]
783 This option influences the output format of the profile data. It
784 specifies whether numerical positions are always specified as
785 absolute values or are allowed to be relative to previous
786 numbers. This shrinks the file size.
787 --combine-dumps=<no|yes> [default: no]
789 When enabled, when multiple profile data parts are to be
790 generated these parts are appended to the same output file. Not
791 recommended.
792 --dump-every-bb=<count> [default: 0, never]
794 Dump profile data every count basic blocks. Whether a dump is
795 needed is only checked when Valgrind's internal scheduler is
796 run. Therefore, the minimum setting useful is about 100000. The
797 count is a 64-bit value to make long dump periods possible.
798 --dump-before=<function>
800 Dump when entering function.
801 --zero-before=<function>
803 Zero all costs when entering function.
804 --dump-after=<function>
806 Dump when leaving function.
807 --instr-atstart=<yes|no> [default: yes]
809 Specify if you want Callgrind to start simulation and profiling
810 from the beginning of the program. When set to no, Callgrind
811 will not be able to collect any information, including calls,
812 but it will have at most a slowdown of around 4, which is the
813 minimum Valgrind overhead. Instrumentation can be interactively
814 enabled via callgrind_control -i on.
815 Note that the resulting call graph will most probably not
817 contain main, but will contain all the functions executed after
818 instrumentation was enabled. Instrumentation can also
819 programatically enabled/disabled. See the Callgrind include file
820 callgrind.h for the macro you have to use in your source code.
821 For cache simulation, results will be less accurate when
823 switching on instrumentation later in the program run, as the
824 simulator starts with an empty cache at that moment. Switch on
825 event collection later to cope with this error.
826 --collect-atstart=<yes|no> [default: yes]
828 Specify whether event collection is enabled at beginning of the
829 profile run.
830 To only look at parts of your program, you have two
832 possibilities:
833 1. Zero event counters before entering the program part you want
835 to profile, and dump the event counters to a file after
836 leaving that program part.
837 2. Switch on/off collection state as needed to only see event
839 counters happening while inside of the program part you want
840 to profile.
841 The second option can be used if the program part you want to
843 profile is called many times. Option 1, i.e. creating a lot of
844 dumps is not practical here.
845 Collection state can be toggled at entry and exit of a given
847 function with the option --toggle-collect. If you use this
848 option, collection state should be disabled at the beginning.
849 Note that the specification of --toggle-collect implicitly sets
850 --collect-state=no.
851 Collection state can be toggled also by inserting the client
853 request CALLGRIND_TOGGLE_COLLECT ; at the needed code positions.
854 --toggle-collect=<function>
856 Toggle collection on entry/exit of function.
857 --collect-jumps=<no|yes> [default: no]
859 This specifies whether information for (conditional) jumps
860 should be collected. As above, callgrind_annotate currently is
861 not able to show you the data. You have to use KCachegrind to
862 get jump arrows in the annotated code.
863 --collect-systime=<no|yes> [default: no]
865 This specifies whether information for system call times should
866 be collected.
867 --simulate-cache=<yes|no> [default: no]
869 Specify if you want to do full cache simulation. By default,
870 only instruction read accesses will be profiled.
871 --simulate-wb=<yes|no> [default: no]
873 Specify whether write-back behavior should be simulated,
874 allowing to distinguish L2 caches misses with and without write
875 backs. The cache model of Cachegrind/Callgrind does not specify
876 write-through vs. write-back behavior, and this also is not
877 relevant for the number of generated miss counts. However, with
878 explicit write-back simulation it can be decided whether a miss
879 triggers not only the loading of a new cache line, but also if a
880 write back of a dirty cache line had to take place before. The
881 new dirty miss events are I2dmr, D2dmr, and D2dmw, for misses
882 because of instruction read, data read, and data write,
883 respectively. As they produce two memory transactions, they
884 should account for a doubled time estimation in relation to a
885 normal miss.
886 --simulate-hwpref=<yes|no> [default: no]
888 Specify whether simulation of a hardware prefetcher should be
889 added which is able to detect stream access in the second level
890 cache by comparing accesses to separate to each page. As the
891 simulation can not decide about any timing issues of
892 prefetching, it is assumed that any hardware prefetch triggered
893 succeeds before a real access is done. Thus, this gives a
894 best-case scenario by covering all possible stream accesses.
895 --cacheuse=<yes|no> [default: no]
897 Specify whether cache line use should be collected. For every
898 cache line, from loading to it being evicted, the number of
899 accesses as well as the number of actually used bytes is
900 determined. This behavior is related to the code which triggered
901 loading of the cache line. In contrast to miss counters, which
902 shows the position where the symptoms of bad cache behavior
903 (i.e. latencies) happens, the use counters try to pinpoint at
904 the reason (i.e. the code with the bad access behavior). The new
905 counters are defined in a way such that worse behavior results
906 in higher cost. AcCost1 and AcCost2 are counters showing bad
907 temporal locality for L1 and L2 caches, respectively. This is
908 done by summing up reciprocal values of the numbers of accesses
909 of each cache line, multiplied by 1000 (as only integer costs
910 are allowed). E.g. for a given source line with 5 read accesses,
911 a value of 5000 AcCost means that for every access, a new cache
912 line was loaded and directly evicted afterwards without further
913 accesses. Similarly, SpLoss1/2 shows bad spatial locality for L1
914 and L2 caches, respectively. It gives the spatial loss count of
915 bytes which were loaded into cache but never accessed. It
916 pinpoints at code accessing data in a way such that cache space
917 is wasted. This hints at bad layout of data structures in
918 memory. Assuming a cache line size of 64 bytes and 100 L1 misses
919 for a given source line, the loading of 6400 bytes into L1 was
920 triggered. If SpLoss1 shows a value of 3200 for this line, this
921 means that half of the loaded data was never used, or using a
922 better data layout, only half of the cache space would have been
923 needed. Please note that for cache line use counters, it
924 currently is not possible to provide meaningful inclusive costs.
925 Therefore, inclusive cost of these counters should be ignored.
926 --I1=<size>,<associativity>,<line size>
928 Specify the size, associativity and line size of the level 1
929 instruction cache.
930 --D1=<size>,<associativity>,<line size>
932 Specify the size, associativity and line size of the level 1
933 data cache.
934 --L2=<size>,<associativity>,<line size>
936 Specify the size, associativity and line size of the level 2
937 cache.
938
940 --track-lockorders=no|yes [default: yes]
941 When enabled (the default), Helgrind performs lock order
942 consistency checking. For some buggy programs, the large number
943 of lock order errors reported can become annoying, particularly
944 if you're only interested in race errors. You may therefore find
945 it helpful to disable lock order checking.
946 --history-level=none|approx|full [default: full]
948 --history-level=full (the default) causes Helgrind collects
949 enough information about "old" accesses that it can produce two
950 stack traces in a race report -- both the stack trace for the
951 current access, and the trace for the older, conflicting access.
952 Collecting such information is expensive in both speed and
954 memory, particularly for programs that do many inter-thread
955 synchronisation events (locks, unlocks, etc). Without such
956 information, it is more difficult to track down the root causes
957 of races. Nonetheless, you may not need it in situations where
958 you just want to check for the presence or absence of races, for
959 example, when doing regression testing of a previously race-free
960 program.
961 --history-level=none is the opposite extreme. It causes Helgrind
963 not to collect any information about previous accesses. This can
964 be dramatically faster than --history-level=full.
965 --history-level=approx provides a compromise between these two
967 extremes. It causes Helgrind to show a full trace for the later
968 access, and approximate information regarding the earlier
969 access. This approximate information consists of two stacks, and
970 the earlier access is guaranteed to have occurred somewhere
971 between program points denoted by the two stacks. This is not as
972 useful as showing the exact stack for the previous access (as
973 --history-level=full does), but it is better than nothing, and
974 it is almost as fast as --history-level=none.
975 --conflict-cache-size=N [default: 1000000]
977 This flag only has any effect at --history-level=full.
978 Information about "old" conflicting accesses is stored in a
980 cache of limited size, with LRU-style management. This is
981 necessary because it isn't practical to store a stack trace for
982 every single memory access made by the program. Historical
983 information on not recently accessed locations is periodically
984 discarded, to free up space in the cache.
985 This option controls the size of the cache, in terms of the
987 number of different memory addresses for which conflicting
988 access information is stored. If you find that Helgrind is
989 showing race errors with only one stack instead of the expected
990 two stacks, try increasing this value.
991 The minimum value is 10,000 and the maximum is 30,000,000
993 (thirty times the default value). Increasing the value by 1
994 increases Helgrind's memory requirement by very roughly 100
995 bytes, so the maximum value will easily eat up three extra
996 gigabytes or so of memory.
997
999 --check-stack-var=<yes|no> [default: no]
1000 Controls whether DRD detects data races on stack variables.
1001 Verifying stack variables is disabled by default because most
1002 programs do not share stack variables over threads.
1003 --exclusive-threshold=<n> [default: off]
1005 Print an error message if any mutex or writer lock has been held
1006 longer than the time specified in milliseconds. This option
1007 enables the detection of lock contention.
1008 --first-race-only=<yes|no> [default: no]
1010 Whether to report only the first data race that has been
1011 detected on a memory location or all data races that have been
1012 detected on a memory location.
1013 --report-signal-unlocked=<yes|no> [default: yes]
1015 Whether to report calls to pthread_cond_signal and
1016 pthread_cond_broadcast where the mutex associated with the
1017 signal through pthread_cond_wait or pthread_cond_timed_waitis
1018 not locked at the time the signal is sent. Sending a signal
1019 without holding a lock on the associated mutex is a common
1020 programming error which can cause subtle race conditions and
1021 unpredictable behavior. There exist some uncommon
1022 synchronization patterns however where it is safe to send a
1023 signal without holding a lock on the associated mutex.
1024 --segment-merging=<yes|no> [default: yes]
1026 Controls segment merging. Segment merging is an algorithm to
1027 limit memory usage of the data race detection algorithm.
1028 Disabling segment merging may improve the accuracy of the
1029 so-called 'other segments' displayed in race reports but can
1030 also trigger an out of memory error.
1031 --segment-merging-interval=<n> [default: 10]
1033 Perform segment merging only after the specified number of new
1034 segments have been created. This is an advanced configuration
1035 option that allows to choose whether to minimize DRD's memory
1036 usage by choosing a low value or to let DRD run faster by
1037 choosing a slightly higher value. The optimal value for this
1038 parameter depends on the program being analyzed. The default
1039 value works well for most programs.
1040 --shared-threshold=<n> [default: off]
1042 Print an error message if a reader lock has been held longer
1043 than the specified time (in milliseconds). This option enables
1044 the detection of lock contention.
1045 --show-confl-seg=<yes|no> [default: yes]
1047 Show conflicting segments in race reports. Since this
1048 information can help to find the cause of a data race, this
1049 option is enabled by default. Disabling this option makes the
1050 output of DRD more compact.
1051 --show-stack-usage=<yes|no> [default: no]
1053 Print stack usage at thread exit time. When a program creates a
1054 large number of threads it becomes important to limit the amount
1055 of virtual memory allocated for thread stacks. This option makes
1056 it possible to observe how much stack memory has been used by
1057 each thread of the the client program. Note: the DRD tool itself
1058 allocates some temporary data on the client thread stack. The
1059 space necessary for this temporary data must be allocated by the
1060 client program when it allocates stack memory, but is not
1061 included in stack usage reported by DRD.
1062 --trace-addr=<address> [default: none]
1064 Trace all load and store activity for the specified address.
1065 This option may be specified more than once.
1066 --trace-barrier=<yes|no> [default: no]
1068 Trace all barrier activity.
1069 --trace-cond=<yes|no> [default: no]
1071 Trace all condition variable activity.
1072 --trace-fork-join=<yes|no> [default: no]
1074 Trace all thread creation and all thread termination events.
1075 --trace-mutex=<yes|no> [default: no]
1077 Trace all mutex activity.
1078 --trace-rwlock=<yes|no> [default: no]
1080 Trace all reader-writer lock activity.
1081 --trace-semaphore=<yes|no> [default: no]
1083 Trace all semaphore activity.
1084
1086 --heap=<yes|no> [default: yes]
1087 Specifies whether heap profiling should be done.
1088 --heap-admin=<size> [default: 8]
1090 If heap profiling is enabled, gives the number of administrative
1091 bytes per block to use. This should be an estimate of the
1092 average, since it may vary. For example, the allocator used by
1093 glibc on Linux requires somewhere between 4 to 15 bytes per
1094 block, depending on various factors. That allocator also
1095 requires admin space for freed blocks, but Massif cannot account
1096 for this.
1097 --stacks=<yes|no> [default: yes]
1099 Specifies whether stack profiling should be done. This option
1100 slows Massif down greatly, and so is off by default. Note that
1101 Massif assumes that the main stack has size zero at start-up.
1102 This is not true, but doing otherwise accurately is difficult.
1103 Furthermore, starting at zero better indicates the size of the
1104 part of the main stack that a user program actually has control
1105 over.
1106 --depth=<number> [default: 30]
1108 Maximum depth of the allocation trees recorded for detailed
1109 snapshots. Increasing it will make Massif run somewhat more
1110 slowly, use more memory, and produce bigger output files.
1111 --alloc-fn=<name>
1113 Functions specified with this option will be treated as though
1114 they were a heap allocation function such as malloc. This is
1115 useful for functions that are wrappers to malloc or new, which
1116 can fill up the allocation trees with uninteresting information.
1117 This option can be specified multiple times on the command line,
1118 to name multiple functions.
1119 Note that the named function will only be treated this way if it
1121 is the top entry in a stack trace, or just below another
1122 function treated this way. For example, if you have a function
1123 malloc1 that wraps malloc, and malloc2 that wraps malloc1, just
1124 specifying --alloc-fn=malloc2 will have no effect. You need to
1125 specify --alloc-fn=malloc1 as well. This is a little
1126 inconvenient, but the reason is that checking for allocation
1127 functions is slow, and it saves a lot of time if Massif can stop
1128 looking through the stack trace entries as soon as it finds one
1129 that doesn't match rather than having to continue through all
1130 the entries.
1131 Note that C++ names are demangled. Note also that overloaded C++
1133 names must be written in full. Single quotes may be necessary to
1134 prevent the shell from breaking them up. For example:
1135 --alloc-fn='operator new(unsigned, std::nothrow_t const&)'
1137 --ignore-fn=<name>
1140 Any direct heap allocation (i.e. a call to malloc, new, etc, or
1141 a call to a function named by an --alloc-fn option) that occurs
1142 in a function specified by this option will be ignored. This is
1143 mostly useful for testing purposes. This option can be specified
1144 multiple times on the command line, to name multiple functions.
1145 Any realloc of an ignored block will also be ignored, even if
1147 the realloc call does not occur in an ignored function. This
1148 avoids the possibility of negative heap sizes if ignored blocks
1149 are shrunk with realloc.
1150 The rules for writing C++ function names are the same as for
1152 --alloc-fn above.
1153 --threshold=<m.n> [default: 1.0]
1155 The significance threshold for heap allocations, as a percentage
1156 of total memory size. Allocation tree entries that account for
1157 less than this will be aggregated. Note that this should be
1158 specified in tandem with ms_print's option of the same name.
1159 --peak-inaccuracy=<m.n> [default: 1.0]
1161 Massif does not necessarily record the actual global memory
1162 allocation peak; by default it records a peak only when the
1163 global memory allocation size exceeds the previous peak by at
1164 least 1.0%. This is because there can be many local allocation
1165 peaks along the way, and doing a detailed snapshot for every one
1166 would be expensive and wasteful, as all but one of them will be
1167 later discarded. This inaccuracy can be changed (even to 0.0%)
1168 via this option, but Massif will run drastically slower as the
1169 number approaches zero.
1170 --time-unit=<i|ms|B> [default: i]
1172 The time unit used for the profiling. There are three
1173 possibilities: instructions executed (i), which is good for most
1174 cases; real (wallclock) time (ms, i.e. milliseconds), which is
1175 sometimes useful; and bytes allocated/deallocated on the heap
1176 and/or stack (B), which is useful for very short-run programs,
1177 and for testing purposes, because it is the most reproducible
1178 across different machines.
1179 --detailed-freq=<n> [default: 10]
1181 Frequency of detailed snapshots. With --detailed-freq=1, every
1182 snapshot is detailed.
1183 --max-snapshots=<n> [default: 100]
1185 The maximum number of snapshots recorded. If set to N, for all
1186 programs except very short-running ones, the final number of
1187 snapshots will be between N/2 and N.
1188 --massif-out-file=<file> [default: massif.out.%p]
1190 Write the profile data to file rather than to the default output
1191 file, massif.out.<pid>. The %p and %q format specifiers can be
1192 used to embed the process ID and/or the contents of an
1193 environment variable in the name, as is the case for the core
1194 option --log-file.
1195
1197 --enable-sg-checks=no|yes [default: yes]
1198 By default, Ptrcheck checks for overruns of stack, global and
1199 heap arrays. With --enable-sg-checks=no, the stack and global
1200 array checks are omitted, and only heap checking is performed.
1201 This can be useful because the stack and global checks are quite
1202 expensive, so omitting them speeds Ptrcheck up a lot.
1203 --partial-loads-ok=<yes|no> [default: no]
1205 This option has the same meaning as it does for Memcheck.
1206 Controls how Ptrcheck handles word-sized, word-aligned loads
1208 which partially overlap the end of heap blocks -- that is, some
1209 of the bytes in the word are validly addressable, but others are
1210 not. When yes, such loads do not produce an address error. When
1211 no (the default), loads from partially invalid addresses are
1212 treated the same as loads from completely invalid addresses: an
1213 illegal heap access error is issued.
1214 Note that code that behaves in this way is in violation of the
1216 the ISO C/C++ standards, and should be considered broken. If at
1217 all possible, such code should be fixed. This option should be
1218 used only as a last resort.
1219
1221 --bb-out-file=<name> [default: bb.out.%p]
1222 This option selects the name of the basic block vector file. The
1223 %p and %q format specifiers can be used to embed the process ID
1224 and/or the contents of an environment variable in the name, as
1225 is the case for the core option --log-file.
1226 --pc-out-file=<name> [default: pc.out.%p]
1228 This option selects the name of the PC file. This file holds
1229 program counter addresses and function name info for the various
1230 basic blocks. This can be used in conjunction with the basic
1231 block vector file to fast-forward via function names instead of
1232 just instruction counts. The %p and %q format specifiers can be
1233 used to embed the process ID and/or the contents of an
1234 environment variable in the name, as is the case for the core
1235 option --log-file.
1236 --interval-size=<number> [default: 100000000]
1238 This option selects the size of the interval to use. The default
1239 is 100 million instructions, which is a commonly used value.
1240 Other sizes can be used; smaller intervals can help programs
1241 with finer-grained phases. However smaller interval size can
1242 lead to accuracy issues due to warm-up effects (When
1243 fast-forwarding the various architectural features will be
1244 un-initialized, and it will take some number of instructions
1245 before they "warm up" to the state a full simulation would be at
1246 without the fast-forwarding. Large interval sizes tend to
1247 mitigate this.)
1248 --instr-count-only [default: no]
1250 This option tells the tool to only display instruction count
1251 totals, and to not generate the actual basic block vector file.
1252 This is useful for debugging, and for gathering instruction
1253 count info without generating the large basic block vector
1254 files.
1255
1257 --basic-counts=<no|yes> [default: yes]
1258 When enabled, Lackey prints the following statistics and
1259 information about the execution of the client program:
1260 1. The number of calls to the function specified by the --fnname
1262 option (the default is main). If the program has had its
1263 symbols stripped, the count will always be zero.
1264 2. The number of conditional branches encountered and the number
1266 and proportion of those taken.
1267 3. The number of superblocks entered and completed by the
1269 program. Note that due to optimisations done by the JIT, this
1270 is not at all an accurate value.
1271 4. The number of guest (x86, amd64, ppc, etc.) instructions and
1273 IR statements executed. IR is Valgrind's RISC-like
1274 intermediate representation via which all instrumentation is
1275 done.
1276 5. Ratios between some of these counts.
1278 6. The exit code of the client program.
1280 --detailed-counts=<no|yes> [default: no]
1282 When enabled, Lackey prints a table containing counts of loads,
1283 stores and ALU operations, differentiated by their IR types. The
1284 IR types are identified by their IR name ("I1", "I8", ...
1285 "I128", "F32", "F64", and "V128").
1286 --trace-mem=<no|yes> [default: no]
1288 When enabled, Lackey prints the size and address of almost every
1289 memory access made by the program. See the comments at the top
1290 of the file lackey/lk_main.c for details about the output
1291 format, how it works, and inaccuracies in the address trace.
1292 Note that this option produces immense amounts of output.
1293 --trace-superblocks=<no|yes> [default: no]
1295 When enabled, Lackey prints out the address of every superblock
1296 (a single entry, multiple exit, linear chunk of code) executed
1297 by the program. This is primarily of interest to Valgrind
1298 developers. See the comments at the top of the file
1299 lackey/lk_main.c for details about the output format. Note that
1300 this option produces large amounts of output.
1301 --fnname=<name> [default: main]
1303 Changes the function for which calls are counted when
1304 --basic-counts=yes is specified.
1305
1307 cg_annotate(1), callgrind_annotate(1), callgrind_control(1),
1308 ms_print(1), $INSTALL/share/doc/valgrind/html/index.html or
1309 http://www.valgrind.org/docs/manual/index.html.
1310
1312 The Valgrind developers.
1313 This manpage was written by Andres Roldan <aroldan@debian.org> and the
1315 Valgrind developers.
1316Release 3.5.0 08/19/2009 VALGRIND(1)