Lire les rapports

Un rapport de Valgrind comporte trois parties :

• Le préfixe de l’identifiant du processus sur chaque ligne
• Un ou plusieurs blocs d’erreurs au moment où elles surviennent
• Un HEAP and LEAK SUMMARY final à la fin du processus

Apprendre à lire chaque partie transforme un mur de texte en liste de tâches précise.

Chaque ligne de Valgrind commence par ==PID==, par exemple ==12345==.

Il s’agit de l’identifiant du processus, et non d’une partie de la sortie de votre programme. Il vous permet de distinguer les messages de Valgrind de ceux produits par votre programme avec printf lorsqu’ils utilisent tous deux le terminal.

Voici un véritable bloc signalant une écriture invalide :

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

La première ligne indique la catégorie et la taille de l’erreur : 'Invalid write of size 4'.

La taille 4 signifie qu’il s’agit d’un accès de 4 octets, généralement un int. Cette seule ligne vous indique à quelle catégorie de problème vous attendre avant de poursuivre la lecture.

La ligne at correspond à la trame la plus interne, là où l’erreur s’est produite. Chaque ligne by indique un appelant, un niveau plus haut.

Lisez de haut en bas, de la trame la plus profonde à la plus superficielle. La première trame contenant le nom de votre fichier indique presque toujours l’emplacement du problème.

La ligne Address ... situe l’accès par rapport à un bloc connu :

• 0 bytes after a block of size 20 alloc'd — dépassement juste après la fin
• 4 bytes inside a block of size 4 free'd — utilisation après libération
• on thread 1's stack — accès à la pile

Elle indique même où ce bloc a été alloué ou libéré.

À la fin du processus, vous obtenez le bilan des allocations :

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

Une valeur « in use at exit » supérieure à zéro signifie qu’un élément n’a pas été libéré.

Sous le résumé du tas, les fuites sont regroupées par catégorie :

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

Ajoutez --leak-check=full pour associer une trace à chaque bloc perdu.

La toute dernière ligne comptabilise tout :

ERROR SUMMARY: 2 errors from 2 contexts

Un « contexte » est un emplacement d’erreur unique. Si une ligne défectueuse s’exécute un million de fois dans une boucle, elle correspond toujours à un seul contexte. Votre objectif est 0 errors from 0 contexts.

Traitez le rapport méthodiquement :

• Corrigez d’abord les erreurs d’accès invalide ; elles provoquent des corruptions
• Puis les erreurs de valeur non initialisée
• Ensuite les fuites définitivement et indirectement perdues
• Relancez le programme après chaque correction ; une seule cause première suffit souvent à faire disparaître plusieurs rapports

Certaines erreurs proviennent de bibliothèques que vous ne pouvez pas corriger, comme l’environnement d’exécution C ou un pilote graphique. Générez un fichier de suppressions pour les masquer sans dissimuler vos propres problèmes.

--gen-suppressions=all affiche des entrées de suppression prêtes à l’emploi que vous enregistrez, puis transmettez à nouveau avec --suppressions=file.

Interprétez une ligne d’un rapport.

Vous savez maintenant lire les rapports de Valgrind de bout en bout :

• Le préfixe ==PID== précède les lignes de Valgrind et les distingue de la sortie du programme
• Chaque bloc d’erreur indique la catégorie, la taille, la trace de la pile et une indication d’adresse
• Les résumés HEAP/LEAK rendent compte des allocations et de la mémoire perdue
• Le ERROR SUMMARY compte les contextes uniques ; visez zéro

Traitez d’abord les erreurs d’accès, puis les fuites, en relançant le programme au fur et à mesure.