Berichte lesen

Ein Valgrind-Bericht besteht aus drei Teilen:

• dem Präfix mit der Prozess-ID in jeder Zeile
• einem oder mehreren Fehlerblöcken, sobald sie auftreten
• einer abschließenden HEAP and LEAK SUMMARY beim Beenden

Wenn Sie lernen, jeden Teil zu lesen, wird aus einer Textwand eine präzise To-do-Liste.

Jede Valgrind-Zeile beginnt mit ==PID==, zum Beispiel ==12345==.

Dies ist die Prozess-ID und kein Bestandteil der Ausgabe Ihres Programms. So können Sie Valgrinds Meldungen von den printf-Ausgaben Ihres Programms unterscheiden, wenn beide dasselbe Terminal verwenden.

Hier sehen Sie einen echten Block für einen ungültigen Schreibzugriff:

==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)

Die erste Zeile nennt Fehlerart und Größe: „Invalid write of size 4“.

Größe 4 bedeutet einen 4 Byte großen Zugriff, typischerweise auf ein int. Diese eine Zeile sagt Ihnen, welche Fehlerkategorie Sie erwarten können, bevor Sie weiterlesen.

Die Zeile mit at ist der innerste Stackframe, in dem der Fehler aufgetreten ist. Jede Zeile mit by nennt einen Aufrufer, also eine Ebene darüber.

Lesen Sie den Trace von oben nach unten, vom tiefsten zum obersten Frame. Der erste Frame mit dem Namen Ihrer Datei ist fast immer die Fehlerstelle.

Die Zeile Address ... ordnet den Zugriff relativ zu einem bekannten Block ein:

• 0 bytes after a block of size 20 alloc'd — Überlauf direkt hinter dem Ende
• 4 bytes inside a block of size 4 free'd — Verwendung nach der Freigabe
• on thread 1's stack — ein Stackzugriff

Außerdem wird angezeigt, wo dieser Block allokiert oder freigegeben wurde.

Beim Beenden erhalten Sie eine Übersicht über die Speicherallokationen:

==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

Ein Wert größer als null bei „in use at exit“ bedeutet, dass etwas nicht freigegeben wurde.

Unterhalb der Heap-Zusammenfassung werden Leaks kategorisiert:

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

Fügen Sie --leak-check=full hinzu, um für jeden verlorenen Block einen Trace anzuzeigen.

Die allerletzte Zeile zählt alle Fehler:

ERROR SUMMARY: 2 errors from 2 contexts

Ein „Kontext“ ist eine eindeutige Fehlerstelle. Wenn eine fehlerhafte Zeile eine Million Mal in einer Schleife ausgeführt wird, handelt es sich trotzdem nur um einen Kontext. Ihr Ziel lautet 0 errors from 0 contexts.

Arbeiten Sie den Bericht systematisch ab:

• Beheben Sie zuerst Fehler bei ungültigen Speicherzugriffen; sie verursachen Beschädigungen
• Danach folgen Fehler mit nicht initialisierten Werten
• Dann beheben Sie Leaks, die definitely und indirectly lost sind
• Führen Sie das Programm nach jeder Korrektur erneut aus; eine gemeinsame Ursache beseitigt oft mehrere Meldungen

Einige Fehler stammen aus Bibliotheken, die Sie nicht ändern können, etwa aus der C-Laufzeitumgebung oder einem Grafiktreiber. Erzeugen Sie eine Suppressionsdatei, um diese Meldungen auszublenden, ohne Ihre eigenen Fehler zu verbergen.

--gen-suppressions=all gibt sofort verwendbare Suppression-Einträge aus, die Sie speichern und anschließend mit --suppressions=file wieder übergeben.

Interpretieren Sie eine Zeile eines Berichts.

Sie können Valgrind-Berichte jetzt vollständig lesen:

• ==PID==-Präfixe kennzeichnen Valgrind-Zeilen und trennen sie von der Programmausgabe
• Jeder Fehlerblock enthält Art, Größe, Stacktrace und einen Adresshinweis
• HEAP- und LEAK-Zusammenfassungen dokumentieren Allokationen und verlorenen Speicher
• Die ERROR SUMMARY zählt eindeutige Kontexte; streben Sie null an

Analysieren Sie zuerst Zugriffsfehler und danach Leaks. Führen Sie das Programm dabei immer wieder aus.