--leak-check=<no|summary|yes|full> [default: summary]
When enabled, search for memory leaks when the client program
finishes. If set to summary, it says how many leaks occurred.
If set to full or yes, each individual leak will be shown in
detail and/or counted as an error, as specified by the
options --show-leak-kinds and --errors-for-leak-kinds.
If --xml=yes is given, memcheck will automatically use the
value --leak-check=full. You can use --show-leak-kinds=none
to reduce the size of the xml output if you are not
interested in the leak results.
--leak-resolution=<low|med|high> [default: high]
When doing leak checking, determines how willing Memcheck is
to consider different backtraces to be the same for the
purposes of merging multiple leaks into a single leak report.
When set to low, only the first two entries need match. When
med, four entries have to match. When high, all entries need
to match.
For hardcore leak debugging, you probably want to use
--leak-resolution=high together with --num-callers=40 or some
such large number.
Note that the --leak-resolution setting does not affect
Memcheck's ability to find leaks. It only changes how the
results are presented.
--show-leak-kinds=<set> [default: definite,possible]
Specifies the leak kinds to show in a full leak search, in
one of the following ways:
• a comma separated list of one or more of definite
indirect possible reachable.
• all to specify the complete set (all leak kinds). It is
equivalent to
--show-leak-kinds=definite,indirect,possible,reachable.
• none for the empty set.
--errors-for-leak-kinds=<set> [default: definite,possible]
Specifies the leak kinds to count as errors in a full leak
search. The <set> is specified similarly to --show-leak-kinds
--leak-check-heuristics=<set> [default: all]
Specifies the set of leak check heuristics to be used during
leak searches. The heuristics control which interior pointers
to a block cause it to be considered as reachable. The
heuristic set is specified in one of the following ways:
• a comma separated list of one or more of stdstring
length64 newarray multipleinheritance.
• all to activate the complete set of heuristics. It is
equivalent to
--leak-check-heuristics=stdstring,length64,newarray,multipleinheritance.
• none for the empty set.
Note that these heuristics are dependent on the layout of the
objects produced by the C++ compiler. They have been tested
with some gcc versions (e.g. 4.4 and 4.7). They might not
work properly with other C++ compilers.
--show-reachable=<yes|no> , --show-possibly-lost=<yes|no>
These options provide an alternative way to specify the leak
kinds to show:
• --show-reachable=no --show-possibly-lost=yes is
equivalent to --show-leak-kinds=definite,possible.
• --show-reachable=no --show-possibly-lost=no is equivalent
to --show-leak-kinds=definite.
• --show-reachable=yes is equivalent to
--show-leak-kinds=all.
Note that --show-possibly-lost=no has no effect if
--show-reachable=yes is specified.
--xtree-leak=<no|yes> [no]
If set to yes, the results for the leak search done at exit
will be output in a 'Callgrind Format' execution tree file.
Note that this automatically sets the options
--leak-check=full and --show-leak-kinds=all, to allow xtree
visualisation tools such as kcachegrind to select what kind
to leak to visualise. The produced file will contain the
following events:
• RB : Reachable Bytes
• PB : Possibly lost Bytes
• IB : Indirectly lost Bytes
• DB : Definitely lost Bytes (direct plus indirect)
• DIB : Definitely Indirectly lost Bytes (subset of DB)
• RBk : reachable Blocks
• PBk : Possibly lost Blocks
• IBk : Indirectly lost Blocks
• DBk : Definitely lost Blocks
The increase or decrease for all events above will also be
output in the file to provide the delta (increase or
decrease) between 2 successive leak searches. For example,
iRB is the increase of the RB event, dPBk is the decrease of
PBk event. The values for the increase and decrease events
will be zero for the first leak search done.
See Execution Trees for a detailed explanation about
execution trees.
--xtree-leak-file=<filename> [default: xtleak.kcg.%p]
Specifies that Valgrind should produce the xtree leak report
in the specified file. Any %p, %q or %n sequences appearing
in the filename are expanded in exactly the same way as they
are for --log-file. See the description of --log-file for
details.
See Execution Trees for a detailed explanation about
execution trees formats.
--undef-value-errors=<yes|no> [default: yes]
Controls whether Memcheck reports uses of undefined value
errors. Set this to no if you don't want to see undefined
value errors. It also has the side effect of speeding up
Memcheck somewhat. AddrCheck (removed in Valgrind 3.1.0)
functioned like Memcheck with --undef-value-errors=no.
--track-origins=<yes|no> [default: no]
Controls whether Memcheck tracks the origin of uninitialised
values. By default, it does not, which means that although it
can tell you that an uninitialised value is being used in a
dangerous way, it cannot tell you where the uninitialised
value came from. This often makes it difficult to track down
the root problem.
When set to yes, Memcheck keeps track of the origins of all
uninitialised values. Then, when an uninitialised value error
is reported, Memcheck will try to show the origin of the
value. An origin can be one of the following four places: a
heap block, a stack allocation, a client request, or
miscellaneous other sources (eg, a call to brk).
For uninitialised values originating from a heap block,
Memcheck shows where the block was allocated. For
uninitialised values originating from a stack allocation,
Memcheck can tell you which function allocated the value, but
no more than that -- typically it shows you the source
location of the opening brace of the function. So you should
carefully check that all of the function's local variables
are initialised properly.
Performance overhead: origin tracking is expensive. It halves
Memcheck's speed and increases memory use by a minimum of
100MB, and possibly more. Nevertheless it can drastically
reduce the effort required to identify the root cause of
uninitialised value errors, and so is often a programmer
productivity win, despite running more slowly.
Accuracy: Memcheck tracks origins quite accurately. To avoid
very large space and time overheads, some approximations are
made. It is possible, although unlikely, that Memcheck will
report an incorrect origin, or not be able to identify any
origin.
Note that the combination --track-origins=yes and
--undef-value-errors=no is nonsensical. Memcheck checks for
and rejects this combination at startup.
--partial-loads-ok=<yes|no> [default: yes]
Controls how Memcheck handles 32-, 64-, 128- and 256-bit
naturally aligned loads from addresses for which some bytes
are addressable and others are not. When yes, such loads do
not produce an address error. Instead, loaded bytes
originating from illegal addresses are marked as
uninitialised, and those corresponding to legal addresses are
handled in the normal way.
When no, loads from partially invalid addresses are treated
the same as loads from completely invalid addresses: an
illegal-address error is issued, and the resulting bytes are
marked as initialised.
Note that code that behaves in this way is in violation of
the ISO C/C++ standards, and should be considered broken. If
at all possible, such code should be fixed.
--expensive-definedness-checks=<no|auto|yes> [default: auto]
Controls whether Memcheck should employ more precise but also
more expensive (time consuming) instrumentation when checking
the definedness of certain values. In particular, this
affects the instrumentation of integer adds, subtracts and
equality comparisons.
Selecting --expensive-definedness-checks=yes causes Memcheck
to use the most accurate analysis possible. This minimises
false error rates but can cause up to 30% performance
degradation.
Selecting --expensive-definedness-checks=no causes Memcheck
to use the cheapest instrumentation possible. This maximises
performance but will normally give an unusably high false
error rate.
The default setting, --expensive-definedness-checks=auto, is
strongly recommended. This causes Memcheck to use the minimum
of expensive instrumentation needed to achieve the same false
error rate as --expensive-definedness-checks=yes. It also
enables an instrumentation-time analysis pass which aims to
further reduce the costs of accurate instrumentation.
Overall, the performance loss is generally around 5% relative
to --expensive-definedness-checks=no, although this is
strongly workload dependent. Note that the exact
instrumentation settings in this mode are architecture
dependent.
--keep-stacktraces=alloc|free|alloc-and-free|alloc-then-free|none
[default: alloc-and-free]
Controls which stack trace(s) to keep for malloc'd and/or
free'd blocks.
With alloc-then-free, a stack trace is recorded at allocation
time, and is associated with the block. When the block is
freed, a second stack trace is recorded, and this replaces
the allocation stack trace. As a result, any "use after free"
errors relating to this block can only show a stack trace for
where the block was freed.
With alloc-and-free, both allocation and the deallocation
stack traces for the block are stored. Hence a "use after
free" error will show both, which may make the error easier
to diagnose. Compared to alloc-then-free, this setting
slightly increases Valgrind's memory use as the block
contains two references instead of one.
With alloc, only the allocation stack trace is recorded (and
reported). With free, only the deallocation stack trace is
recorded (and reported). These values somewhat decrease
Valgrind's memory and cpu usage. They can be useful depending
on the error types you are searching for and the level of
detail you need to analyse them. For example, if you are only
interested in memory leak errors, it is sufficient to record
the allocation stack traces.
With none, no stack traces are recorded for malloc and free
operations. If your program allocates a lot of blocks and/or
allocates/frees from many different stack traces, this can
significantly decrease cpu and/or memory required. Of course,
few details will be reported for errors related to heap
blocks.
Note that once a stack trace is recorded, Valgrind keeps the
stack trace in memory even if it is not referenced by any
block. Some programs (for example, recursive algorithms) can
generate a huge number of stack traces. If Valgrind uses too
much memory in such circumstances, you can reduce the memory
required with the options --keep-stacktraces and/or by using
a smaller value for the option --num-callers.
If you want to use --xtree-memory=full memory profiling (see
Execution Trees), then you cannot specify
--keep-stacktraces=free or --keep-stacktraces=none.
--freelist-vol=<number> [default: 20000000]
When the client program releases memory using free (in C) or
delete (C++), that memory is not immediately made available
for re-allocation. Instead, it is marked inaccessible and
placed in a queue of freed blocks. The purpose is to defer as
long as possible the point at which freed-up memory comes
back into circulation. This increases the chance that
Memcheck will be able to detect invalid accesses to blocks
for some significant period of time after they have been
freed.
This option specifies the maximum total size, in bytes, of
the blocks in the queue. The default value is twenty million
bytes. Increasing this increases the total amount of memory
used by Memcheck but may detect invalid uses of freed blocks
which would otherwise go undetected.
--freelist-big-blocks=<number> [default: 1000000]
When making blocks from the queue of freed blocks available
for re-allocation, Memcheck will in priority re-circulate the
blocks with a size greater or equal to --freelist-big-blocks.
This ensures that freeing big blocks (in particular freeing
blocks bigger than --freelist-vol) does not immediately lead
to a re-circulation of all (or a lot of) the small blocks in
the free list. In other words, this option increases the
likelihood to discover dangling pointers for the "small"
blocks, even when big blocks are freed.
Setting a value of 0 means that all the blocks are
re-circulated in a FIFO order.
--workaround-gcc296-bugs=<yes|no> [default: no]
When enabled, assume that reads and writes some small
distance below the stack pointer are due to bugs in GCC 2.96,
and does not report them. The "small distance" is 256 bytes
by default. Note that GCC 2.96 is the default compiler on
some ancient Linux distributions (RedHat 7.X) and so you may
need to use this option. Do not use it if you do not have to,
as it can cause real errors to be overlooked. A better
alternative is to use a more recent GCC in which this bug is
fixed.
You may also need to use this option when working with GCC
3.X or 4.X on 32-bit PowerPC Linux. This is because GCC
generates code which occasionally accesses below the stack
pointer, particularly for floating-point to/from integer
conversions. This is in violation of the 32-bit PowerPC ELF
specification, which makes no provision for locations below
the stack pointer to be accessible.
This option is deprecated as of version 3.12 and may be
removed from future versions. You should instead use
--ignore-range-below-sp to specify the exact range of offsets
below the stack pointer that should be ignored. A suitable
equivalent is --ignore-range-below-sp=1024-1.
--ignore-range-below-sp=<number>-<number>
This is a more general replacement for the deprecated
--workaround-gcc296-bugs option. When specified, it causes
Memcheck not to report errors for accesses at the specified
offsets below the stack pointer. The two offsets must be
positive decimal numbers and -- somewhat counterintuitively
-- the first one must be larger, in order to imply a
non-wraparound address range to ignore. For example, to
ignore 4 byte accesses at 8192 bytes below the stack pointer,
use --ignore-range-below-sp=8192-8189. Only one range may be
specified.
--show-mismatched-frees=<yes|no> [default: yes]
When enabled, Memcheck checks that heap blocks are
deallocated using a function that matches the allocating
function. That is, it expects free to be used to deallocate
blocks allocated by malloc, delete for blocks allocated by
new, and delete[] for blocks allocated by new[]. If a
mismatch is detected, an error is reported. This is in
general important because in some environments, freeing with
a non-matching function can cause crashes.
There is however a scenario where such mismatches cannot be
avoided. That is when the user provides implementations of
new/new[] that call malloc and of delete/delete[] that call
free, and these functions are asymmetrically inlined. For
example, imagine that delete[] is inlined but new[] is not.
The result is that Memcheck "sees" all delete[] calls as
direct calls to free, even when the program source contains
no mismatched calls.
This causes a lot of confusing and irrelevant error reports.
--show-mismatched-frees=no disables these checks. It is not
generally advisable to disable them, though, because you may
miss real errors as a result.
--ignore-ranges=0xPP-0xQQ[,0xRR-0xSS]
Any ranges listed in this option (and multiple ranges can be
specified, separated by commas) will be ignored by Memcheck's
addressability checking.
--malloc-fill=<hexnumber>
Fills blocks allocated by malloc, new, etc, but not by
calloc, with the specified byte. This can be useful when
trying to shake out obscure memory corruption problems. The
allocated area is still regarded by Memcheck as undefined --
this option only affects its contents. Note that
--malloc-fill does not affect a block of memory when it is
used as argument to client requests VALGRIND_MEMPOOL_ALLOC or
VALGRIND_MALLOCLIKE_BLOCK.
--free-fill=<hexnumber>
Fills blocks freed by free, delete, etc, with the specified
byte value. This can be useful when trying to shake out
obscure memory corruption problems. The freed area is still
regarded by Memcheck as not valid for access -- this option
only affects its contents. Note that --free-fill does not
affect a block of memory when it is used as argument to
client requests VALGRIND_MEMPOOL_FREE or
VALGRIND_FREELIKE_BLOCK.
