RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 juillet 2016
-
9 nov. 2007 à 16:43
RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 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"
gbourgeois0019
Messages postés152Date d'inscriptionlundi 3 avril 2006StatutMembreDernière intervention 2 juin 20081 9 nov. 2007 à 21:03
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 !
mezaya
Messages postés202Date d'inscriptiondimanche 18 mai 2003StatutMembreDernière intervention 6 mars 2010 10 nov. 2007 à 14:55
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.
RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 juillet 2016 10 nov. 2007 à 02:29
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"
RV2931
Messages postés185Date d'inscriptionsamedi 21 mai 2005StatutMembreDernière intervention16 juillet 2016 10 nov. 2007 à 15:12
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"