aide valgrind requise

Question

Mon application provoque 10m de fuite de mémoire dans un scénario. Mais quand j'ai débogué avec valgrind, ce qui suit est le résumé de la fuite.

812 ==18074== LEAK SUMMARY:  
813 ==18074== definitely lost: 0 bytes in 0 blocks.  
814 ==18074==  possibly lost: 3,424 bytes in 20 blocks. 
815 ==18074== still reachable: 10,422 bytes in 47 blocks. 
816 ==18074==   suppressed: 0 bytes in 0 blocks. 

Que puis-je dériver de ce résumé? puis-je dire qu'il n'y a pas de problème avec l'application?

quelqu'un peut-il expliquer ce qui suit également? quel pourrait être le problème dans la création de thread? Je ne passe même pas quelque chose de dynamiquement attribué comme argument de thread.

795 ==18074== 2,448 bytes in 17 blocks are possibly lost in loss record 32 of 33 
796 ==18074== at 0x40056BF: calloc (vg_replace_malloc.c:279) 
797 ==18074== by 0xC0D71A: _dl_allocate_tls (in /lib/ld-2.3.4.so) 
798 ==18074== by 0xD8A91E: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-2.3.4.so) 
799 ==18074== by 0x8056A28: Server::intithreads() (ServerProcess.cpp:899) 
800 ==18074== by 0x8054E39: main (ServerProcess.h:85) 

Answer 1

Il peut y avoir des problèmes avec votre application en fonction du rapport de fuite de mémoire. Si "définitivement perdu", "éventuellement perdu" ou "encore joignable" est supérieur à 0, vous avez une fuite de mémoire. "Définitivement perdu" signifie qu'il y avait de la mémoire non gérée, et aucune variable pointant dessus n'existait à la fin du programme, parce que par exemple les variables étaient hors de portée. Cela signifie que la fuite sera difficile à réparer, car vous devrez trouver où vous les avez jetés.

« Peut-être perdue » indique que la mémoire était unfreed, et vous avez avoir des variables pointant vers elle à la fin du programme, mais ils ne sont probablement pas utilisables pour libérer la mémoire, parce qu'ils étaient des pointeurs internes plutôt que des pointeurs vers le début du bloc, que vous devez passer à free. "Toujours joignable" indique qu'il y avait de la mémoire non gérée, mais qu'elle était directement pointée par des variables à la fin du programme. Cela signifie que même s'il y a une fuite, ce n'est pas celle qui peut se développer et n'est donc pas si grave.

Answer 2

Je ne m'inquiéterais pas beaucoup des blocs "encore joignables". Puisque tous les blocs sont libérés à la sortie du programme, il n'est pas nécessaire de libérer spécifiquement chaque bloc. Pour améliorer la situation, vous pouvez essayer de libérer des blocs aux stades intermédiaires de votre programme, au-delà desquels vous n'en avez pas besoin. En revanche, les blocs «éventuellement perdus» sont de nature un peu plus grave.

Dans tous les cas, de la Valgrind manual:

"Toujours accessible". Ceci couvre les cas pour les blocs BBB montrés ci-dessous. Un pointeur de départ ou une chaîne de pointeurs de départ vers le bloc est trouvé. Depuis le bloc est toujours pointé, le programmeur pourrait, au moins en principe, l'ont libéré avant la sortie du programme . Parce que ceux-ci sont très commun et sans doute pas un problème, Memcheck ne rapportera pas ces blocs individuellement sauf si - show-reachable = yes est spécifié.

Pointer chain    
-------------    
RRR ------------> BBB  
RRR ---> AAA ---> BBB 

"Peut-être perdu". Ceci couvre les cas pour les blocs BBB montrés ci-dessous. Cela signifie qu'une chaîne d'un ou plusieurs pointeurs au bloc a été trouvée, mais à au moins l'un des pointeurs est un pointeur intérieur .Cela pourrait être juste une valeur aléatoire dans la mémoire qui arrive à point dans un bloc, et donc vous ne devrait pas considérer cela ok sauf si vous savez que vous avez des pointeurs intérieurs.

Pointer chain    
-------------    
RRR ------?-----> BBB  
RRR ---> AAA -?-> BBB  
RRR -?-> AAA ---> BBB  
RRR -?-> AAA -?-> BBB