Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 28/01/2010, à 14:59

nalian34

valgrind

j'ai écrit un programme en c++ et j'ai utilisé Valgrind pour voir s'il n'y avait pas des problèmes de fuite mémoire

j'ai éxécuté mon programme de la manière suivante :

valgrind --leak-check=full --show-reachable=yes ./Tetris

et j'ai obtenu en résultat :

==10075== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1)
==10075== malloc/free: in use at exit: 56 bytes in 1 blocks.
==10075== malloc/free: 8,504 allocs, 8,503 frees, 1,621,181 bytes allocated.
==10075== For counts of detected errors, rerun with: -v
==10075== searching for pointers to 1 not-freed blocks.
==10075== checked 2,076,688 bytes.
==10075== 
==10075== 56 bytes in 1 blocks are still reachable in loss record 1 of 1
==10075==    at 0x4C220BC: calloc (vg_replace_malloc.c:397)
==10075==    by 0x409A0B8: (within /usr/lib/libGL.so.169.12)
==10075==    by 0x409A306: _init (in /usr/lib/libGL.so.169.12)
==10075==    by 0x400E185: (within /lib/ld-2.7.so)
==10075==    by 0x400E2AD: (within /lib/ld-2.7.so)
==10075==    by 0x4000A99: (within /lib/ld-2.7.so)
==10075==    by 0x0: ???
==10075==    by 0x7FF0003FA: ???
==10075== 
==10075== LEAK SUMMARY:
==10075==    definitely lost: 0 bytes in 0 blocks.
==10075==      possibly lost: 0 bytes in 0 blocks.
==10075==    still reachable: 56 bytes in 1 blocks.
==10075==         suppressed: 0 bytes in 0 blocks.

qqn peut m'aider à interpréter cette phrase :

56 bytes in 1 blocks are still reachable in loss record 1 of 1

c'est une erreur dans mon code?

Hors ligne

#2 Le 28/01/2010, à 15:28

Karl_le_rouge

Re : valgrind

C'est probablement un faux positif, mais on ne peut rien affirmer sans avoir le code en question sous les yeux.
Tu fais bien de préciser que ton code est en C++, certaines implémentations de la bibliothèque standard utiliser un allocateur mémoire de type memory pool qui ne libére pas immédiatement la mémoire (ce n'est pas un bogue mais une optimisation).
Normalement, tu peux forcer la libération avec la variable d'environnement GLIBCXX_FORCE_NEW=1 temporairement pour Valgrind.

Hors ligne

#3 Le 28/01/2010, à 15:46

nalian34

Re : valgrind

merci pour les renseignement, j'ai essayé avec GLIBCXX_FORCE_NEW=1 mais c'est pareil.
Ce n'est pas bien grave, c'était par curiosité pour comprendre ce que me dit Valgrind, c'est la première fois que je l'utilise tongue

si j'ai bien compris, en sortie de mon programme il y a 56 bytes de mémoire encore alloué et 1 pointeur qui pointe dessus? mais à priori pas de quoi s'inquiéter puisque c'est dans libGL.so

si c'est ça je mets en résolu

Hors ligne

#4 Le 28/01/2010, à 17:45

AuraHxC

Re : valgrind

Valgrind est extrêmement verbeux, c'est une vraie piplette donc il arrive souvent qu'il est des trucs sur les libs que tu utilises etc... faut pas vraiment y faire attention. SI tu veux utiliser valgrind pour tes programmes (et c'est une bonne chose), regarde en général les premiers messages, il concerne ton code (si bien sur il y a un soucis dans ton code sinon aucun intérêt de l'utiliser).

Hors ligne