This is a short howto on getting and viewing profiling with valgrind's callgrind tool and kcachegrind. It only shows the way I have found easiest so far, and generally serves mostly as a getting started guide. The specific example below is for profiling b10-auth.

Environment or system setup

No special system setup is necessary, apart from installing valgrind (and for the last step, kcachegrind, though some results can be read with callgrind_annotate as well).

If you are profiling one specific executable in the source tree, you need to setup your shell environment to have the correct environment settings. Currently, the easiest way to do this is to source the script tests/lettuce/

From the build directory:

source tests/lettuce/


No special build actions are necessary. You probably want to build with -g and optimization, but these are set by default.


Profiling data is stored if the profiled program is used with valgrind's callgrind tool

valgrind --tool=callgrind <program>

For bind10 this is a small problem, since we usually only want to profile one specific module at a time. But it can still be done with a few tricks; Let's take b10-auth as an example.

Profiling b10-auth

First of all, build bind10, run it, and configure it as needed (including the wanted b10-auth configuration).

To run a module separately from the rest, the shell environment needs to be set up if you run from the build tree (see above).

Disable b10-auth in bind10 (so that it can be run manually);

echo -e "config remove Boss/components b10-auth\nconfig commit" | bindctl

Then run b10-auth with valgrind. Do not run src/bin/auth/b10-auth directly as this is a libtool shellscript that calls a number of other programs; if you are running this from the build tree, the canonical method is to call the valgrind through libtool:

libtool --mode=execute valgrind --tool=callgrind src/bin/auth/b10-auth

Depending on your system, and if you have used the include file mentioned earlier, it may also be possible to run src/bin/auth/.libs/lt-b10-auth.

valgrind --tool=callgrind src/bin/auth/.libs/lt-b10-auth

Now in your current directory, a file called callgrind.out.<PID> is created. This is empty until the program finishes, but that behaviour can be overridden with command line options.

Run your tests, and stop b10-auth (either by ctrl-c in the shell you ran it in, or by the bindctl command Auth shutdown).

Viewing results


The callgrind_annotate tool present the collected data in a somewhat readable format;

callgrind_annotate --tree=both --inclusive=yes [callgrind.out.PID] | less

It shows the number of instruction reads. The --tree=both arguments tells annotate to print both callers and callees, and --inclusive=yes adds the callee costs to the counts (set to no to only show instructions counted in the functions themselves). If the callgrind file is not specified it will use the first one it finds in the current directory.

For a bit more source context, you can add --auto=yes (and --context=<number> for more or less surrounding source lines).


callgrind_annotate can be useful, but kcachegrind is much more informative; it provides a number of views and calculations that callgrind_annotate does not (cycle detection being a possible important one).

kcachegrind offers a nice graphical tool to inspect results; the most important view in this is the callgraph view (one of the tabs on the bottom right).

In the directory where you ran valgrind, run kcachegrind:

kcachegrind callgrind.out.<PID>

Running unit tests under Valgrind

The build system now supports running unit tests under Valgrind. For this purpose, it adds new make targets (check-valgrind and check-valgrind-suppress). To run tests, configure the BIND10 source tree as usual. If Valgrind is found on the system, configure will print a message at the end of the configure output that it has been found. After this, you can run tests under Valgrind as follows:

# Running a regular check
make check

# Running unit tests under Valgrind.
# This reports all memcheck tool errors.
make check-valgrind

# Running unit tests under Valgrind with suppressions enabled.
# This only report memcheck tool errors that are not suppressed by the suppressions files found in src/ directory.
make check-valgrind-suppress

The latter two check targets are supported only when run from the top build directory. If Valgrind was not detected by configure, making the latter two targets will exit with an error.

Note that Valgrind is used only for unit tests written in C++. Python unittests are not run under Valgrind.

See also

Last modified 5 years ago Last modified on Jun 24, 2012, 5:26:23 PM