Détection de fuite mémoire avec Visual StudioRésolu

Question

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 #include 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: 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: 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 · Accepted Answer

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 !

RV2931 · Answer

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"

mezaya · Answer

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

RV2931 · Answer

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"

Détection de fuite mémoire avec Visual Studio

4 réponses

Votre réponse

Discussions similaires