For tools that use their own version of malloc (e.g. Memcheck,
Massif, Helgrind, DRD), the following options apply.
--alignment=<number> [default: 8 or 16, depending on the
platform]
By default Valgrind's malloc, realloc, etc, return a block
whose starting address is 8-byte aligned or 16-byte aligned
(the value depends on the platform and matches the platform
default). This option allows you to specify a different
alignment. The supplied value must be greater than or equal
to the default, less than or equal to 4096, and must be a
power of two.
--redzone-size=<number> [default: depends on the tool]
Valgrind's malloc, realloc, etc, add padding blocks before
and after each heap block allocated by the program being run.
Such padding blocks are called redzones. The default value
for the redzone size depends on the tool. For example,
Memcheck adds and protects a minimum of 16 bytes before and
after each block allocated by the client. This allows it to
detect block underruns or overruns of up to 16 bytes.
Increasing the redzone size makes it possible to detect
overruns of larger distances, but increases the amount of
memory used by Valgrind. Decreasing the redzone size will
reduce the memory needed by Valgrind but also reduces the
chances of detecting over/underruns, so is not recommended.
--xtree-memory=none|allocs|full [none]
Tools replacing Valgrind's malloc, realloc, etc, can
optionally produce an execution tree detailing which piece of
code is responsible for heap memory usage. See Execution
Trees for a detailed explanation about execution trees.
When set to none, no memory execution tree is produced.
When set to allocs, the memory execution tree gives the
current number of allocated bytes and the current number of
allocated blocks.
When set to full, the memory execution tree gives 6 different
measurements : the current number of allocated bytes and
blocks (same values as for allocs), the total number of
allocated bytes and blocks, the total number of freed bytes
and blocks.
Note that the overhead in cpu and memory to produce an xtree
depends on the tool. The overhead in cpu is small for the
value allocs, as the information needed to produce this
report is maintained in any case by the tool. For massif and
helgrind, specifying full implies to capture a stack trace
for each free operation, while normally these tools only
capture an allocation stack trace. For Memcheck, the cpu
overhead for the value full is small, as this can only be
used in combination with --keep-stacktraces=alloc-and-free or
--keep-stacktraces=alloc-then-free, which already records a
stack trace for each free operation. The memory overhead
varies between 5 and 10 words per unique stacktrace in the
xtree, plus the memory needed to record the stack trace for
the free operations, if needed specifically for the xtree.
--xtree-memory-file=<filename> [default: xtmemory.kcg.%p]
Specifies that Valgrind should produce the xtree memory
report in the specified file. Any %p or %q 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.
If the filename contains the extension .ms, then the produced
file format will be a massif output file format. If the
filename contains the extension .kcg or no extension is
provided or recognised, then the produced file format will be
a callgrind output format.
See Execution Trees for a detailed explanation about
execution trees formats.
