Valgrind basics is a tool that can find bugs in compiled code by running compiled executable and instrumenting it. According to docs works best on code compiled with -O0 or -O1 and might report false positives with highly optimized code (i.e. compiled with -O2).

Basic usage

valgrind ${prog-to-run} ${arg1} ${arg2} ...

Checking for memory access errors and memory leaks:

valgrind --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=16 ${prog-to-run}

Profiling memory usage:

valgrind --tool=massif ${prog-to-run}
gv massif.${pid}.ps
most massif.${pid}.txt

Profiling CPU usage:

valgrind --tool=callgrind ${prog-to-run}

or:

valgrind --tool=callgrind --instr-atstart=no ${prog-to-run}

and then:

callgrind_control -i on
callgrind_control -i off

It generates callgrind.out.<pid> file (where <pid> is process id of the program). Use kcachegrind GUI tool to view the results.

Profiling sections of the code

• #include <valgrind/callgrind.h>
• wrap the section to profile with CALLGRIND_TOGGLE_COLLECT macros
• add --collect-atstart=no so that valgrind doesn’t profile from the beginning but only the sections of the code within CALLGRIND_TOGGLE_COLLECT

In other words, if your code looks like:

#include <valgrind/callgrind.h>

CALLGRIND_TOGGLE_COLLECT
foo();
CALLGRIND_TOGGLE_COLLECT

your program is profiled only when foo() function is running.

There’s also an option --instr-atstart=no and CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION macros. In theory you can use this option and insert those 2 macros into the code to speedup profiling (instrumentation slows down valgrind) but in practice valgrind 3.2 crashed when I was using this option.