|Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications|
by J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team
Paperback (6"x9"), 164 pages
RRP £12.95 ($19.95)
5.2 Command-line flags specific to Memcheck
--leak-check=<no|summary|yes|full> [default: summary]When enabled, search for memory leaks when the client program finishes. A memory leak means a malloc'd block, which has not yet been free'd, but to which no pointer can be found. Such a block can never be free'd by the program, since no pointer to it exists. If set to
summary, it says how many leaks occurred. If set to
yes, it gives details of each individual leak.
--show-reachable=<yes|no> [default: no]When disabled, the memory leak detector only shows blocks for which it cannot find a pointer to at all, or it can only find a pointer to the middle of. These blocks are prime candidates for memory leaks. When enabled, the leak detector also reports on blocks which it could find a pointer to. Your program could, at least in principle, have freed such blocks before exit. Contrast this to blocks for which no pointer, or only an interior pointer could be found: they are more likely to indicate memory leaks, because you do not actually have a pointer to the start of the block which you can hand to
free, even if you wanted to.
--leak-resolution=<low|med|high> [default: low]When doing leak checking, determines how willing
memcheckis to consider different backtraces to be the same. 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
--num-callers=40or some such large number. Note however that this can give an overwhelming amount of information, which is why the defaults are 4 callers and low-resolution matching. Note that the
--leak-resolution=setting does not affect
memcheck'sability to find leaks. It only changes how the results are presented.
--freelist-vol=<number> [default: 10000000]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
memcheckwill be able to detect invalid accesses to blocks for some significant period of time after they have been freed. This flag specifies the maximum total size, in bytes, of the blocks in the queue. The default value is ten million bytes. Increasing this increases the total amount of memory used by
memcheckbut may detect invalid uses of freed blocks which would otherwise go undetected.
--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 flag. 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/g++ in which this bug is fixed. You may also need to use this flag when working with gcc/g++ 3.X or 4.X on 32-bit PowerPC Linux. This is because gcc/g++ 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.
--partial-loads-ok=<yes|no> [default: no]Controls how
memcheckhandles 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 flag should be used only as a last resort.
--undef-value-errors=<yes|no> [default: yes]Controls whether
memcheckdetects dangerous uses of undefined value errors. Set this to
noif you don't like seeing undefined value errors; it also has the side effect of speeding
--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 flag only affects its contents.
--free-fill=<hexnumber>Fills blocks freed by ‘free’, ‘delete’, etc, with the specified byte. 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 flag only affects its contents.
|ISBN 0954612051||Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications||See the print edition|