Comprendre la sortie de valgrind

Question

Je suis nouveau sur linux. Comment puis-je interpréter la sortie suivante de

valgrind --tool=memcheck --leak-check=yes ./main 

Il est dit que certains blocs sont perdus. Comment puis-je éliminer les fuites de mémoire.

==2599== HEAP SUMMARY: 
==2599==  in use at exit: 17,327 bytes in 55 blocks 
==2599== total heap usage: 180,597 allocs, 180,542 frees, 15,787,989,675 bytes allocated 
==2599== 
==2599== 9 bytes in 1 blocks are definitely lost in loss record 5 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) 
==2599== by 0x804AD78: CNF::GrowFromParseTree(AndList*, Schema*, Record&) (Comparison.cc:606) 
==2599== by 0x804EE52: main (main.cc:28) 
==2599== 
==2599== 10 bytes in 2 blocks are definitely lost in loss record 6 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) 
==2599== by 0x804AD78: CNF::GrowFromParseTree(AndList*, Schema*, Record&) (Comparison.cc:606) 
==2599== by 0x804EE52: main (main.cc:28) 
==2599== 
==2599== 13 bytes in 1 blocks are definitely lost in loss record 9 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) 
==2599== by 0x804EDF4: main (main.cc:23) 
==2599== 
==2599== 13 bytes in 1 blocks are definitely lost in loss record 10 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) 
==2599== by 0x804EEA4: main (main.cc:37) 
==2599== 
==2599== 188 bytes in 16 blocks are definitely lost in loss record 16 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) 
==2599== by 0x804EDF4: main (main.cc:23) 
==2599== 
==2599== 188 bytes in 16 blocks are definitely lost in loss record 17 of 19 
==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) 
==2599== by 0x41E546F: strdup (strdup.c:43) 
==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) 
==2599== by 0x804EEA4: main (main.cc:37) 
==2599== 
==2599== LEAK SUMMARY: 
==2599== definitely lost: 421 bytes in 37 blocks 
==2599== indirectly lost: 0 bytes in 0 blocks 
==2599==  possibly lost: 0 bytes in 0 blocks 
==2599== still reachable: 16,906 bytes in 18 blocks 
==2599==   suppressed: 0 bytes in 0 blocks 
==2599== Reachable blocks (those to which a pointer was found) are not shown. 
==2599== To see them, rerun with: --leak-check=full --show-reachable=yes 
==2599== 
==2599== For counts of detected and suppressed errors, rerun with: -v 
==2599== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 19 from 8) 

Answer 1

La sortie montre assez clairement la pile pour la fuite où (et a perdu, par exemple. Pas de pointeurs vers qui restent) la mémoire a été allouée, dans les lignes 86 et 115 de Schema.cc (un appel strdup)

Answer 2

de description OpenGroup strdup():

la fonction strdup() renvoie un pointeur vers une nouvelle chaîne, qui est une copie de la chaîne pointée par s1. Le pointeur retourné peut être passé à free(). Un pointeur NULL est renvoyé si la nouvelle chaîne ne peut pas être créée.

En résumé, strdup() appelle malloc(). Vous aurez besoin de free() cette chaîne résultante lorsque vous avez terminé. Bien que, comme vous utilisez C++, je recommande fortement std::string si vous le pouvez. Rappelez-vous, si vous avez vraiment besoin de l'équivalent C string.c_str() l'obtiendra pour vous.