Reading Reports

A Valgrind report has three parts:

• The process ID prefix on every line
• One or more error blocks as they occur
• A final HEAP and LEAK SUMMARY at exit

Learning to read each part turns a wall of text into a precise to-do list.

Every Valgrind line starts with ==PID==, for example ==12345==.

This is the process ID, not part of your program's output. It lets you separate Valgrind's messages from your program's printf when both share the terminal.

Here is a real invalid-write block:

==12345== Invalid write of size 4
==12345== at 0x4005A1: main (prog.c:6)
==12345== Address 0x520304c is 0 bytes after a block of size 20 alloc'd
==12345== at 0x4838B40: malloc
==12345== by 0x40058E: main (prog.c:5)

The first line names the error kind and size: 'Invalid write of size 4'.

Size 4 means a 4-byte access, typically an int. This single line tells you what category of bug to expect before you read any further.

The at line is the innermost frame, where the error happened. Each by line is a caller, one level up.

Read top to bottom as deepest to shallowest. The first frame with your file name is almost always the bug site.

The Address ... line locates the access relative to a known block:

• 0 bytes after a block of size 20 alloc'd — overflow just past the end
• 4 bytes inside a block of size 4 free'd — use after free
• on thread 1's stack — a stack access

It even shows where that block was allocated or freed.

At exit you get allocation accounting:

==12345== HEAP SUMMARY:
==12345== in use at exit: 20 bytes in 1 blocks
==12345== total heap usage: 3 allocs, 2 frees, 1,044 bytes allocated

'in use at exit' greater than zero means something was not freed.

Below the heap summary, leaks are bucketed:

definitely lost: 20 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks

Add --leak-check=full to attach a trace to each lost block.

The very last line counts everything:

ERROR SUMMARY: 2 errors from 2 contexts

A 'context' is a unique error location. If a buggy line runs in a loop a million times, it is still one context. Your goal is 0 errors from 0 contexts.

Work the report methodically:

• Fix invalid access errors first; they cause corruption
• Then uninitialized value errors
• Then definitely and indirectly lost leaks
• Re-run after each fix; one root cause often clears several reports

Some errors come from libraries you cannot fix, like the C runtime or a graphics driver. Generate a suppression file to silence those without hiding your own bugs.

--gen-suppressions=all prints ready-to-use suppression entries you save and pass back with --suppressions=file.

Interpret one line of a report.

You can now read Valgrind reports end to end:

• ==PID== prefixes Valgrind lines, separating them from program output
• Each error block gives kind, size, stack trace, and an address note
• HEAP/LEAK summaries account for allocations and lost memory
• ERROR SUMMARY counts unique contexts; aim for zero

Triage access errors first, then leaks, re-running as you go.