C Language
Valgrind

Syntaxe

• Valgrind nom-programme optionnel-arguments < entrée de test

Remarques

Courir Valgrind

valgrind ./my-program arg1 arg2 < test-input

Cela exécutera votre programme et produira un rapport sur les allocations et les dé-allocations qu'il a effectuées. Il vous avertira également des erreurs courantes telles que l'utilisation de mémoire non initialisée, le déréférencement de pointeurs vers des endroits étranges, la suppression de la fin des blocs alloués à l'aide de malloc ou la libération de blocs.

Ajouter des drapeaux

Vous pouvez également activer d'autres tests, tels que:

valgrind -q --tool=memcheck --leak-check=yes ./my-program arg1 arg2 < test-input

Voir valgrind --help pour plus d'informations sur les nombreuses options, ou consultez la documentation à l' adresse http://valgrind.org/ pour des informations détaillées sur la signification de la sortie.

Octets perdus - Oublier de libérer

Voici un programme qui appelle malloc mais pas gratuit:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
    char *s;

    s = malloc(26); // the culprint 

    return 0;
}

Sans arguments supplémentaires, valgrind ne cherchera pas cette erreur.

Mais si nous --leak-check=yes ou --tool=memcheck , cela se plaint et affiche les lignes responsables de ces fuites de mémoire si le programme a été compilé en mode debug:

$ valgrind -q --leak-check=yes ./missing_free
==4776== 26 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4776==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==4776==    by 0x80483F8: main (missing_free.c:9)
==4776== 

Si le programme n'est pas compilé en mode débogage (par exemple avec l'indicateur -g dans GCC), il nous indiquera toujours où la fuite s'est produite en termes de la fonction concernée, mais pas les lignes.

Cela nous permet de revenir en arrière et de voir quel bloc a été alloué dans cette ligne et d'essayer de suivre pour voir pourquoi il n'a pas été libéré.

Erreurs les plus fréquentes rencontrées lors de l'utilisation de Valgrind

Valgrind vous fournit les lignes sur lesquelles l'erreur s'est produite à la fin de chaque ligne au format (file.c:line_no) . Les erreurs dans valgrind sont résumées de la manière suivante:

ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Les erreurs les plus courantes incluent:

1. Erreurs de lecture / écriture illégales

==8451== Invalid read of size 2
==8451==    at 0x4E7381D: getenv (getenv.c:84)
==8451==    by 0x4EB1559: __libc_message (libc_fatal.c:80)
==8451==    by 0x4F5256B: __fortify_fail (fortify_fail.c:37)
==8451==    by 0x4F5250F: __stack_chk_fail (stack_chk_fail.c:28)
==8451==    by 0x40059C: main (valg.c:10)
==8451==  Address 0x700000007 is not stack'd, malloc'd or (recently) free'd

Cela se produit lorsque le code commence à accéder à la mémoire qui n'appartient pas au programme. La taille de la mémoire utilisée vous donne également une indication de la variable utilisée.

2. Utilisation de variables non initialisées

==8795== 1 errors in context 5 of 8:
==8795== Conditional jump or move depends on uninitialised value(s)
==8795==    at 0x4E881AF: vfprintf (vfprintf.c:1631)
==8795==    by 0x4E8F898: printf (printf.c:33)
==8795==    by 0x400548: main (valg.c:7)

Selon l’erreur, à la ligne 7 du valg.c main de valg.c , l’appel à printf() transmettait une variable non initialisée à printf .

3. Libération illégale de la mémoire

==8954== Invalid free() / delete / delete[] / realloc()
==8954==    at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8954==    by 0x4005A8: main (valg.c:10)
==8954==  Address 0x5203040 is 0 bytes inside a block of size 240 free'd
==8954==    at 0x4C2EDEB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8954==    by 0x40059C: main (valg.c:9)
==8954==  Block was alloc'd at
==8954==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8954==    by 0x40058C: main (valg.c:7)

Selon valgrind, le code libérait la mémoire illégalement (une seconde fois) à la ligne 10 de valg.c , alors qu’il était déjà libéré à la ligne 9 et que le bloc lui-même était affecté à la ligne 7 .