Finding unused memory with Valgrind Massif

Updated: April 19, 2023

Valgrind Massif takes detailed heap snapshots to record dynamic memory allocation by program region. The IDE displays this memory breakdown so you can easily find space leaks, which occur when the program doesn't free unneeded memory.

Note: All Valgrind tools can be loaded and run from the command line. However, using the IDE is more convenient because it automates much of the setup by setting Valgrind command options based on UI fields and by copying the analysis results into the host workspace.
To find space leaks with Valgrind Massif:
  1. In the launch bar, expand the Launch Configuration dropdown (which is in the middle) and select the project in which you want to check for leaks.
  2. In the Launch Target dropdown (on the right), select the target for running your application.
  3. In the Launch Mode dropdown (on the left), select Check.
  4. Click the Edit button (Icon: Edit button) on the right of the Launch Configuration dropdown.
  5. In the configuration editor window, access the Valgrind controls by clicking the Check tab on the right and then the Valgrind radio button near the top of this tab.
  6. Select Massif from the Tool to run dropdown.
  7. Optional: You can change any settings to customize what gets reported in the Valgrind results.
    The Massif tab lets you specify how often to take detailed heap snapshots and the maximum depth of the allocation trees to report in the results.
  8. Click OK to save the configuration changes and close the window.
  9. In the launch bar, click the Check button (Icon: Check button).

The IDE switches to the QNX Analysis perspective. If necessary, the IDE first builds the binary before uploading it to the target. To analyze the application, the IDE instructs Valgrind to execute the uploaded binary with Massif instrumentation. Then, it creates a session for storing the Valgrind results; this new session is displayed in the Analysis Sessions view. When the program terminates, Valgrind writes the results to a log file, which the IDE copies into the directory for the new session.

The memory measurements taken at each snapshot are graphed in the Heap Chart window (for more information, see Analyzing heap memory usage with Valgrind Massif). The Valgrind view, which is displayed at the bottom, presents the heap snapshot data in a table. The rows for detailed snapshots are indicated with the heap tree icon (Icon: Heap tree). Double-clicking in one of these rows displays the heap trees for all detailed snapshots, with the entries for the selected snapshot expanded.

Sometimes, a program might repeatedly allocate blocks and maintain their pointers so they remain accessible but never free these blocks even though their contents aren't needed anymore. In the Valgrind User Manual, this situation is referred to as a “space leak” because it's not a conventional memory leak but the program does waste space. In this manual, we also refer to it as an “implicit leak”. To detect this situation, you can look for increasing memory consumption in a specific place indicated in the heap trees, as seen here:

Screenshot of Valgrind view containing several detailed snapshots that show increasing memory allocated in main()

The heap trees should show location information for functions in shared libraries. If you don't see this information, you must manually configure the loading of debug symbols.

Here, the program is accumulating a lot of heap memory at one particular allocation point in main(). You would want to review the surrounding code to see if any blocks don't need to be kept in memory for as long. Whether a block is needed depends on your program logic; Massif shows you the evolution of memory usage but you must examine your code closely to learn which blocks can be deallocated.

Note: You can run multiple Valgrind sessions concurrently, using the same tool or different tools, on the same application or different applications. Valgrind log files always contain the PIDs of the Valgrind processes, so their names are always distinct.