Discussion :

[awabi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[nikko34]

Rerun with --leak-check=full

il faut que tu relances avec cette option pour avoir le détail

[white_tentacle]

En gros :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

==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)

==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.

==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

[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

[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

[awabi]

Merci beaucoup pour vos aides.

[awabi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[bruno_pages]

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

==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

==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

[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?

[nikko34]

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.

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 )

[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.

[nikko34]

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 ?