Valgrind erreurs même si tous les blocs tas ont été libérés

Question

J'ai récemment pris l'habitude d'exécuter tous mes programmes à travers valgrind pour vérifier les fuites de mémoire, mais la plupart de ses résultats ont été un peu cryptiques pour moi.

Pour ma dernière course, valgrind -v m'a donné:

All heap blocks were freed -- no leaks are possible 

Cela signifie mon programme couvert pour fuites de mémoire, non?

Alors qu'est-ce que cette erreur signifie? Mon programme ne lit-il pas certains blocs de mémoire correctement?

ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 9) 

1 errors in context 1 of 1: 
Invalid read of size 4 
    at 0x804885B: findPos (in /home/a.out) 
    by 0xADD918: start_thread (pthread_create.c:301) 
    by 0xA26CCD: clone (clone.S:133) 
Address 0x4a27108 is 0 bytes after a block of size 40 alloc'd 
    at 0x4005BDC: malloc (vg_replace_malloc.c:195) 
    by 0x804892F: readInput (in /home/a.out) 
    by 0xADD918: start_thread (pthread_create.c:301) 
    by 0xA26CCD: clone (clone.S:133) 

used_suppression:  14 dl-hack3-cond-1 

Aussi, quelles sont les erreurs dites "supprimées" ici?

Answer 1

1. Oui, vous êtes grandement couvert, ne pas penser que valgrind peut facilement manquer une fuite dans le code utilisateur
2. votre erreur signifie que vous avez probablement avez une erreur +1 dans l'indexation d'une variable tableau . les lignes qui valgrind vous dire doivent être précis, de sorte que vous devrait facilement constater que, à condition que vous compilez tout votre code avec -g
3. erreurs supprimées sont habituellement de bibliothèques système, qui ont parfois de petites fuites ou des choses indétectable comme l'état variables de threads. votre page de manuel devrait indiquer le fichier de suppression qui est utilisé par défaut

Answer 2

Cela semble évident ... mais il pourrait être intéressant de souligner que le message "no leaks are possible" ne signifie pas que votre programme ne peut pas fuir; cela signifie simplement qu'il n'a pas fui dans la configuration sous laquelle il a été testé. Si je lance ce qui suit avec valgrind sans paramètres de ligne de commande, cela m'indique qu'aucune fuite n'est possible. Mais il fuit si je fournis un paramètre de ligne de commande.

int main(int argc, char* argv[]) 
{ 
    if (argc > 1) 
     malloc(5); 
    printf("Enter any command line arg to cause a leak\n"); 
} 

Answer 3

Vérification des fuites de mémoire est l'une des raisons d'utiliser valgrind, mais je dirais une meilleure raison est de trouver plus graves erreurs dans votre code, comme l'utilisation d'un indice de tableau non valide ou déréférencement d'un pointeur non initialisé ou pointeur vers la mémoire libérée. Il est bon que valgrind vous indique que les chemins de code que vous avez utilisés lors de l'exécution de valgrind n'ont pas entraîné de fuites de mémoire, mais ne vous laissez pas ignorer les rapports d'erreurs plus graves, comme celle que vous avez commise. voir ici.

Comme d'autres l'ont suggéré, réexécuter valgrind après compilation avec des informations de débogage (-g) serait une bonne étape suivante.