valgrind fuite mémoire

Version imprimable

Bonjour à tous,

J'ai exécuté mon programme avec valgrind pour détecter les fuites mémoires et j'ai le résultat ci dessous. Est ce que quelqu'un pourrait m'aider à le comprendre?
Merci d'avance.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
==8246== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==8246== malloc/free: in use at exit: 48 bytes in 4 blocks.
==8246== malloc/free: 14 allocs, 10 frees, 176 bytes allocated.
==8246== For counts of detected errors, rerun with: -v
==8246== searching for pointers to 4 not-freed blocks.
==8246== checked 167,776 bytes.
==8246== 
==8246== LEAK SUMMARY:
==8246==    definitely lost: 48 bytes in 4 blocks.
==8246==      possibly lost: 0 bytes in 0 blocks.
==8246==    still reachable: 0 bytes in 0 blocks.
==8246==         suppressed: 0 bytes in 0 blocks.
==8246== Rerun with --leak-check=full to see details of leaked memory.

28/05/2010, 17h13
nikko34

Rerun with --leak-check=full

il faut que tu relances avec cette option pour avoir le détail
28/05/2010, 17h22
white_tentacle

En gros :

Code:

==8246== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)

Bon point : valgrind n'a détecté aucune erreur mémoire (débordement de tableau, pointeur null, etc)

Citation:

==8246== malloc/free: in use at exit: 48 bytes in 4 blocks.

Mauvais point : à la sortie du programme, il restait des blocs utilisés, totalisant 48 octets.

Citation:

==8246== malloc/free: 14 allocs, 10 frees, 176 bytes allocated.

Sur 14 allocations, seules 10 ont été libérées. Au total, tu as alloué 176 bytes.

La suite est un résumé de tout ça :)
28/05/2010, 18h26
bruno_pages

mais valgrind détaille plus que cela, avec l'option --leak-check=full on sait de qu'elles classes il s'agit (si new) et la pile des appels ayant réaliser les allocations des blocks/instances perdus
29/05/2010, 01h23
LittleWhite

Moi ce que j'adore avec valgrind, c'est qu'il dit quoi faire:

Dans le log du départ
[quote]
==8246== For counts of detected errors, rerun with: -v
[quote]

Après il va dire, faites un check complet:
--leak-check=full

Et puis faut pensé à compiler le programme avec l'option -g ( pour avoir les informations de debugguage ). Ça aide pas mal aussi :)
29/05/2010, 15h20
awabi

Merci beaucoup pour vos aides.

J'ai exécuter avec l'option --leak-check=full et j'ai le résultat suivant (les parties en rouge sont celles que j'ai du mal à comprendre):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
==7232== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==7232== malloc/free: in use at exit: 48 bytes in 4 blocks.
==7232== malloc/free: 14 allocs, 10 frees, 176 bytes allocated.
==7232== For counts of detected errors, rerun with: -v
==7232== searching for pointers to 4 not-freed blocks.
==7232== checked 167,776 bytes.
==7232== 
==7232== 48 (8 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 3
==7232==    at 0x4C25F6C: operator new(unsigned long) (vg_replace_malloc.c:230)
==7232==    by 0x400B91: main (in /home/awabi/Bureau/proj/projet)
==7232== 
==7232== LEAK SUMMARY:
==7232==    definitely lost: 8 bytes in 1 blocks.
==7232==    indirectly lost: 40 bytes in 3 blocks.
==7232==      possibly lost: 0 bytes in 0 blocks.
==7232==    still reachable: 0 bytes in 0 blocks.
==7232==         suppressed: 0 bytes in 0 blocks.

Merci d'avance

30/05/2010, 18h51
bruno_pages

vous êtes sure d'avoir compilé avec l'option -g ? parce qu'il n'y a pas de numéro de ligne

Citation:

==7232== at 0x4C25F6C: operator new(unsigned long) (vg_replace_malloc.c:230)
==7232== by 0x400B91: main (in /home/awabi/Bureau/proj/projet)

la mémoire perdue est liée à un new (et non calloc ou autre) appelé dans main

Citation:

==7232== definitely lost: 8 bytes in 1 blocks.
==7232== indirectly lost: 40 bytes in 3 blocks.

ce qui n'est plus référencé c'est un bloc de 8 octets qui lui même référence directement ou indirectement 3 éléments occupant au total 40 octets
30/05/2010, 19h12
awabi

OK.
Non je n'ai pas compilé avec l'option -g.
Avec les pointeurs intelligents c'est dure de ne pas avoir de fuite mémoire. Je pense que je vais faire une fonction qui me permettra de détecter les fuites en utilisant les zones allouées.. Est ce une bonne idée?
30/05/2010, 21h53
nikko34

Citation:

Envoyé par awabi

OK.
Non je n'ai pas compilé avec l'option -g.
Avec les pointeurs intelligents c'est dure de ne pas avoir de fuite mémoire.

avec les pointeurs intelligents (comme boost::shared_ptr), c'est surtout dur d'en avoir.

Citation:

Je pense que je vais faire une fonction qui me permettra de détecter les fuites en utilisant les zones allouées.. Est ce une bonne idée?

bon sinon à savoir en C++ tu auras de la mémoire alloué dans la lib standard que valgrind prendra pour des fuites mais qui n'en est pas.

Ben le meilleur conseil c'est de compiler comme on te dit, comme ça tu sauras où sont tes fuites, et si ce sont de vrais fuites.

Mais sinon, il y a une methode simple: pour chaque new, un delete. ( ou un pointeur intelligent pour gérer les desallocs )
31/05/2010, 11h48
awabi

Je suis entrain de faire ma propre classe de pointeur intelligent c'est pour cela que les désallocations ne sont pas très bien gérées.
31/05/2010, 14h40
nikko34

Citation:

Envoyé par awabi

Je suis entrain de faire ma propre classe de pointeur intelligent c'est pour cela que les désallocations ne sont pas très bien gérées.

tu as quelque chose contre les shared_ptr ?