Détection de fuite mémoire avec Visual Studio [Résolu]

Messages postés
185
Date d'inscription
samedi 21 mai 2005
Dernière intervention
16 juillet 2016
- 9 nov. 2007 à 16:43 - Dernière réponse :
Messages postés
185
Date d'inscription
samedi 21 mai 2005
Dernière intervention
16 juillet 2016
- 10 nov. 2007 à 15:12
Bonjour,

J'ai vu sur ce post Fuites-Mémoires que l'on pouvait utiliser le débugger de VC pour détecter les fuites mémoires.
Il suffit d'insérer en début du fichier :
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

et d'appeler la fonction _CrtDumpMemoryLeaks();  à la sortie du programme.

Par cette méthode, j'obtient quelque chose du genre :
Detected memory leaks!
Dumping objects ->
......

c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {60} normal block at 0x09714B20, 32 bytes long.
 Data: <H:\C++\dessin.sv> 48 3A 5C 43 2B 2B 5C 64 65 73 73 69 6E 2E 73 76
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {59} normal block at 0x09714AD0, 16 bytes long.
 Data: <         Kq     > CD CD CD CD CD CD CD CD 80 4B 71 09 00 00 00 00
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {58} normal block at 0x09712FC0, 32 bytes long.
 Data: <H:\C++\dessin.sv> 48 3A 5C 43 2B 2B 5C 64 65 73 73 69 6E 2E 73 76
c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {57} normal block at 0x09712F48, 60 bytes long.
 Data: <                > CD CD CD CD 00 CD CD CD CD CD CD CD CD CD CD CD

D'après la MSDN (http://msdn2.microsoft.com/en-us/library/e5ewb1h3(VS.80).aspx) concernant cette méthode débugage,
le numéro contenu dans les accolades {60} représente le numéro de l'allocation mémoire "The memory allocation number (inside the curly braces).", je ne vois pas trop ce que cela représente
le 689 est censé représenté la ligne mais il se situe dans le fichier crtdbg.h qui semble être effectivement un appel à la fonction "new" mais je ne sais pas où cette appel se fait dans mon fichier.

Comment je peux savoir à quel endroit dans mes fichier cette appel à eu lieu ou ce qui a causé cet appel.

J'utilise pas mal de STL::string, normalement, il n'y pas besoin de les libérer ces choses là???

Si quelqu'un a l'habitude de débugger avec cet outils, peut-il m'aider et m'indiquer la méthode de recherche ?? sinon, une autre méthode, sachant que je travaille en win32 avec des classes et fonctions récursives...ce qui fait que j'ai un sacré paquet de memoryleaks

Merci

RV

L'intelligence est la chose la mieux répartie chez l'homme, car quoi qu'il en soit pourvu, il a toujours l'impression d'en avoir assez. "Descartes"
Afficher la suite 

Votre réponse

4 réponses

Meilleure réponse
Messages postés
152
Date d'inscription
lundi 3 avril 2006
Dernière intervention
2 juin 2008
- 9 nov. 2007 à 21:03
3
Merci
Je ne crois pas qu'il y ait vraiment de moyen de déterminer de quelle ligne provient le leak. Par contre moi ce que j'utilise comme strategie, je n'execute qu'une partie de mon code en mettant le reste en commentaire et je vois si cette partie provoque des leaks, et je recommence pour une autre partie et ainsi de suite...

Bien sur cette startegie ne convient pas toujours tout dependant de l'application mais parfois ca va quand meme bien !

________________________________________________________________________
Hardware is what we play with until it breaks, Software is what we play with until it works !

Merci gbourgeois0019 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 86 internautes ce mois-ci

Commenter la réponse de gbourgeois0019
Meilleure réponse
Messages postés
203
Date d'inscription
dimanche 18 mai 2003
Dernière intervention
6 mars 2010
- 10 nov. 2007 à 14:55
3
Merci
si tu veut détecter les leaks mémoire et si tu utilise visual avec l'aoocateur par défaut rien de plus simple. En debug tu ajout dans ton code la ligne suivante : _CrtSetDbgFlag( _CRTDBG_LEAK_CHECK_DF );

CrtSetDbgFlag permet de checker le tas, la stack etc... va voir sur msdn pour plus d'info.

cela va de donner le même résultat que CrtDumpMemoryLeaks(). le nombre entre parenthèse est bien le numéro d'allocation. si ce numéro est identique sur plusieur lancement tu peut breaker au numéro d'allocation spécifier avec la fonction _CrtSetBreakAlloc( numeroAllocation );

tu n'as plus qu'a remonter la stack pour savoir qu'elle bout de code leak.


Voili,Voilou

Merci mezaya 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 86 internautes ce mois-ci

Commenter la réponse de mezaya
Messages postés
185
Date d'inscription
samedi 21 mai 2005
Dernière intervention
16 juillet 2016
- 10 nov. 2007 à 02:29
0
Merci
Oui, le truc c'est que j'utilise plusieurs fonctions récursives et je ne fais pas d'allocation explicite de mémoire ou bien qu'en je fais des new, je passe la référence en paramètre de retour, donc peut-être que ça vient de là, je sais pas, j'ai donc bcp de mal à voir d'où cela provient. Je fais un parseur et j'utilise bcp de STL::string temporaires, mais celles-là sont normalement détruites à chaque fin de fonction, donc j'ai du mal, en plus, j'ose pas filer mon code, il est pas propre, j'ai pas vraiment fait de test de retour pour le moment, mais ça marche quand même, sinon la récursivité planterai, mais bon, je vais essayer de trouver et/ou de rendre mon code propre et on verra ça

Merci

@+

L'intelligence est la chose la mieux répartie chez l'homme, car quoi qu'il en soit pourvu, il a toujours l'impression d'en avoir assez. "Descartes"
Commenter la réponse de RV2931
Messages postés
185
Date d'inscription
samedi 21 mai 2005
Dernière intervention
16 juillet 2016
- 10 nov. 2007 à 15:12
0
Merci
C'est bon,

j'ai trouvé, je faisais des liste chaînées de partout, mais j'avais oublié de gérer les destructeurs tout simplement...
entre autres...


J'ai fait ça en faisant insérant des appels à _CrtDumpMemoryLeaks();
accompagné d'un breakpoint,
D'abord j'éxucute le programme complet en débug et je sauvegarde le résultat, c'est à dire les memory leaks réels, définitifs dans un wordpad.
Après, en mettant des appels à _CrtDumpMemoryLeaks();+ breakpoint on obtient ainsi une liste des zone mémoires allouées temporairement et définitiement,
et en comparant la liste des numéros d'allocation du résultat avec celle que j'ai obtenu à la fin du programme, j'ai repéré les endroits où il y avait des allocations non libérées




voilà la méthode que j'ai utilisée, au moins, ce sera expliqué comment faire, peut-être pas très clairement, mais j'aurai essayé..











RV





L'intelligence est la chose la mieux répartie chez l'homme, car quoi qu'il en soit pourvu, il a toujours l'impression d'en avoir assez. "Descartes"
Commenter la réponse de RV2931

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.