Je souhaite résoudre les fuites de mémoire dans une application native C ++ qui utilise la bibliothèque d'exécution C ++. Puis-je facilement connaître le nombre de blocs actuellement alloués (et éventuellement la taille totale)?
3 Réponses :
Vous pouvez essayer le Massif de Valgrind.
Massif est un profileur de tas. Il mesure la quantité de mémoire utilisée par votre programme. [...] De plus, il y a certaines fuites d'espace qui ne sont pas détectées par les vérificateurs de fuite traditionnels,
Vous pouvez essayer le HeapWalk dans l ' API Heap , pas de bibliothèques tierces nécessaire.
Merci, c'est ce que je cherchais.
En fait, cela m'a aidé à constater qu'il n'y avait pas de fuite dans le tas (nouveau / suppression étaient équilibrés). La faute était dans la désallocation d'autres ressources.
Sous Windows, vous pouvez utiliser Dr Memory, sous linux valgrind. Vous pouvez également utiliser le désinfectant pour fuites avec gcc sous Linux ou clang avec -fsanitize = leak, mais vous obtiendrez également un support d'exécution (vous devez créer un lien vers d'autres bibliothèques pour les désinfectants gcc ou clang).
Qu'essayez-vous de faire? Voulez-vous trouver les fuites ou voulez-vous simplement compter le nombre de blocs alloués? Parce que ce dernier ne sera pas très utile si vous voulez faire le premier.
Le CRT a Outils à faire ceci en supposant que vous utilisez le tas de débogage
C'est comme essayer de savoir si quelqu'un vous vole de l'argent en inspectant le solde de votre compte. Bien sûr, si quelqu'un le fait, cela se reflétera là-bas. Mais cela ne semble pas différent des activités régulières du compte.
@IInspectable: quoi ??? Lorsque vous avez une fuite, le nombre de blocs alloués ne cesse de croître et la taille totale permet d'estimer la taille de la fuite.
De même, si votre application ne perd pas de mémoire, le nombre de blocs alloués peut continuer à augmenter. Supposons maintenant un instant que cela ne s'est jamais produit et que vous avez fait une fuite de mémoire. Et ensuite? Répondre à la question oui / non ne vous a pas permis d'isoler le problème.
@IInspectable: non, la quantité de blocs sans fuite reste limitée. Vous repérez la fuite en sautant des parties du code pour isoler celle incriminée. Notez que je viens de trouver ma fuite de cette façon, dans environ une heure. Il semble que vous adoptiez l'attitude «Je ne veux pas que ce soit vrai».
Pas assez. Je suis la philosophie de Marsellus Wallace ici: "Nous ne voulons pas penser. Nous voulons savoir." Donc, au lieu d'écrire du code qui échantillonne des valeurs scalaires largement inintéressantes, comparez-les, soyez victime de fausses hypothèses, et peut-être trouver le problème, par hasard, j'aurais juste utilisé les fonctionnalités de Debug Heap et que l'application me signale des fuites de mémoire à chaque exécution . Ce rapport comprend le fichier et la ligne de code pour chaque allocation de mémoire qui n'a pas été libérée. Peut-être avons-nous simplement des idées différentes sur ce qui comprend une approche de résolution de problèmes dirigée.
@IInspectable: ironie bien accueillie.