MeeGo 1.2 Harmattan Developer Documentation Develop for the Nokia N9

Using Valgrind

The Valgrind tools suite works by simulating the target process CPU and proxying system calls.

Because Valgrind works by simulating the CPU instructions and instrumenting the binaries on the fly, it provides complete control over the program execution.

Note: Valgrind makes program execution 10-300 times slower than normal, depending on the used Valgrind tool (Massif is the fastest, Callgrind the slowest) and can take a huge amount of memory.

The following Valgrind tools have been tested on the Harmattan device:

  • Cachegrind: cache profiler
  • Callgrind: extension of Cachegrind that provides additional information on call graphs
  • Massif: heap profiler
  • Memcheck: a memory error detector

In addition, the following tools are also available, but have not been tested on the Harmattan device (so their functionality cannot be guaranteed):

  • DHAT
  • DRD
  • Helgrind

Note: You can also use Valgrind tools from Qt Creator. You must download and install them separately before you can use them for code analysis. For more information, see Analyzing Code in Qt documentation online.


source: valgrind

binary: valgrind

Installing Valgrind on the Harmattan device

Install Valgrind through the developer mode applet.

Prerequisite: Developer mode must be enabled.

  1. Select Settings > Security > Developer mode.
  2. Install the Networking bundle package by clicking Install.
  3. You get a notification screen that lists all the applications to be installed in the bundle package. To install, click OK.
  4. A dependency notice appears. Click Accept.

For more information on developer mode and installable tools, see Activating developer mode.

Installing debug symbols

In order to view any useful profiling information at functions level, you have to install debugging symbols. Debug symbols normally come with debugging (-dbg) packages. The easiest way to install all dbg packages required for a given binary is to use debug-dep-install script which comes with the maemo-debug-scripts package. Install maemo-debug-scripts with the developer mode applet. For more information, see maemo-debug-scripts.

Using the tools

Note: For a comprehensive list of the available commands, see the manual reference pages for each tool.


Cachegrind is a cache profiler. It performs detailed simulation of the I1, D1 and L2 caches in your CPU, and so it can accurately pinpoint the sources of cache misses in your code. It identifies the number of cache misses, memory references and instructions executed for each line of source code, with summaries according to function, module and for the whole program. Cachegrind runs programs about 20-100 times slower than normal.

To annotate the source code, use the cg_annotate program.


Callgrind is an extension to Cachegrind. It provides the same information as Cachegrind, but, in addition, it provides information about call graphs. You can visualise the call graphs and view the related source code interactively with a separate KCachegrind UI on your workstation.


DHAT is a Valgrind heap profiler. You can use it to identify:

  • Code points which chew through a lot of heap, even if it is not held onto for very long.
  • Code points which allocate very short-lived blocks.
  • Useless or underused allocations which are allocated but not completely filled in, or are filled in but not subsequently read.
  • Blocks with inefficient layout, such as areas never accessed or with hot fields scattered throughout the block.


DRD detects errors in multi-threaded programs similarly to Helgrind, but uses a different algorithm.


Helgrind is a thread debugger which finds data races in multithreaded programs. It looks for memory locations which are accessed by more than one (POSIX p-)thread, but for which no consistently used (pthread_mutex_) lock can be found. Such locations indicate that synchronisation between threads is missing, which may cause timing-related problems that are hard to identify. It is useful for any program that uses pthreads.


Massif is a heap profiler. It measures how much heap memory your program uses. This includes both the useful space, and the extra bytes allocated for book-keeping and alignment purposes. It can also measure the size of your program's stacks, although it does not do so by default.

Heap profiling can help you reduce the amount of memory your program uses. On modern devices with virtual memory, this provides the following benefits:

  • It can speed up your program and the rest of the system because a smaller program interacts better with your device's caches and avoids paging.
  • If your program uses a lot of memory, it reduces the risk of exhausting your device's swap space and programs needing to abort.

Additionally, there is a class of leaks that are not detected by tools such as Memcheck, which checks for lost references to the allocated memory. That is because the memory is not ever actually lost (a pointer remains to it) but it is not in use. Programs that have leaks such as this can unnecessarily increase the amount of memory they are using over time. Massif can help identify these leaks.

In addition to snapshots of the amount of heap memory used by your program at specific points during its lifetime, Massif (ms_print post-processing utility) also provides ASCII call graphs indicating which parts of your program are responsible for the corresponding allocations.

The collected Massif data can be browsed interactively with a separate (KDE) Massif Visualizer UI on your workstation.


Memcheck detects memory-management problems, and it is aimed primarily at C and C++ programs. When a program is run under Memcheck's supervision, all reads and writes of memory are checked, and the calls to malloc, new, free, or delete are intercepted.

You can use this tool to identify if your program does any of the following:

  • Accesses the memory it is not allowed to access (areas not yet allocated, areas that have been freed, areas past the end of heap blocks, inaccessible areas of the stack).
  • Uses uninitialised values in dangerous ways.
  • Leaks memory.
  • Does bad frees of heap blocks (double frees, mismatched frees).
  • Passes overlapping source and destination memory blocks to memcpy() and related functions.

Memcheck reports these errors as soon as they occur, giving the source line number at which it occurred, and also a stack trace of the functions called to reach that line. Memcheck tracks addressability at the byte-level and initialisation of values at the bit-level. As a result, it can detect the use of single uninitialised bits, and it does not report spurious errors on bitfield operations. Memcheck runs programs about 10-30 times slower than normal.

Known issues

Note the following known issues when using these tools:

  • In ARM, the origin is not reported and Massif crashes if Valgrind is run without --run-libc-freeres=no option. Otherwise Memcheck, Massif, Callgrind and Cachegrind work fine on ARM.

Note: The Harmattan version uses export G_SLICE="always-malloc" to avoid getting bogus leakage reports from Glib GSlice allocator (its TLS usage confuses Valgrind allocation tracking). In Harmattan, Glib is used, for example, in GStreamer.

Further information

For more information on the tools, see the following links: