Valgrind Software, Быстрый старт

Страница: 70 / 319

Memcheck: a memory error detector
--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.
--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. Mem-
check checks for and rejects this combination at startup.
--partial-loads-ok=<yes|no> [default: no]
Controls how Memcheck handles word-sized, word-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 the ISO C/C++ standards, and should be considered
broken. If at all possible, such code should be fixed. This option should be used only as a last resort.
--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.
58