Profile Heap Allocations Using Valgrind Massif

Topic Overview

See Allocation Churn

Valgrind Massif records heap snapshots over time so you can see peak usage and which call stacks allocated it. Chrome's allocator telemetry and Rust's dhat serve the same goal: find leaks, spikes, and unexpected strdup hot paths.

Massif Workflow

Run with --tool=massif, open massif.out in ms_print or massif-visualizer. Look for stairs that never descend (leak) and sudden peaks (batch allocation).

bashCopy
Loading…

• Compile with -g for symbolic stacks
• --pages-as-heap=yes includes mmap allocations
• Peak matters for mobile and embedded caps
• Pair with Callgrind to see if hot functions also allocate

Working Through the Exercise

Keep the relevant documentation open while you implement. When your output disagrees with the reference, trace one failing case by hand before changing random lines.

• Trace first: walk one failing input step by step
• Read the manual: skim the official doc for the mechanism named in this task
• Compare baselines: save measurements from the prior step so speedups are honest

Why for this exercise

You will run Massif on a program with deliberate allocation patterns and identify the top allocator stack. This exercise requires reporting peak bytes and the responsible function.

Your Task

Valgrind's massif answers "where did my heap peak, and who was using it?", and memcheck's leak check answers "what was never freed?". Build a small heap profiler that replays an allocation trace. It tracks useful bytes plus the allocator's per-block admin overhead, finds the peak, breaks the peak down by allocation site, and reports leaks by site at the end.

Input

cCopy
Loading…

Rules

• Time is measured like massif --time-unit=B: the total bytes ever allocated. malloc adds SIZE, and realloc adds only its growth.
• Heap = useful bytes (the sum of live sizes) + extra bytes (admin × live blocks).
• The peak is the first moment the heap total is strictly larger than every earlier total. Check it after each malloc and realloc, and record the live bytes per site at that moment.
• Site breakdowns list every site with a nonzero amount, largest first (ties by site name). Each line gives its share of the useful total, rounded half up to 1 decimal.
• Leaks are the blocks still live at end, grouped by site in order of first appearance.
• Errors: malloc ID: id already live, malloc ID: rejected (negative size), free ID: invalid free, and realloc ID: invalid.

Output

cCopy
Loading…

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Compare peaks on the total, including admin overhead. Many small blocks can make the true peak different from the useful-bytes peak.
2. Freeze the per-site breakdown at the moment of the peak. A later snapshot must not change it.

Hidden tests cover a peak driven by many tiny blocks (overhead dominates), realloc growth and shrink, a zero admin cost, ties between sites, a trace with no leaks, and invalid frees and reallocs.