Comment détecter / éviter les fuites de mémoire dans votre code (non géré)?

Question

Dans unmanaged code C/C++, quelles sont les meilleures pratiques pour détecter les fuites de mémoire? Et des directives de codage à éviter? (Comme si c'est aussi simple que ça ;)

Nous avons utilisé un peu bêtement dans le passé: le fait d'avoir un compteur d'incrémentation pour chaque appel d'allocation mémoire et de décrémentation, tout en libérant de. À la fin du programme, la valeur du compteur doit être égale à zéro.

Je sais que ce n'est pas une grande manière et il ya quelques captures. (Par exemple, si vous êtes à la libération de la mémoire qui a été allouée par une plate-forme de l'API d'appel, le nombre d'allocations ne seront pas correspondre exactement à votre libérant le comte. Bien sûr, ensuite, nous incrémenté le compteur lors de l'appel des appels d'API que la mémoire allouée.)

Je suis dans l'attente de vos expériences, suggestions et peut-être quelques références à des outils qui simplifient.

Cheers

Answer 1

Si votre code C / C ++ est portable sur * nix, peu de choses sont mieux que Valgrind .

Answer 2

Si vous utilisez Visual Studio, Microsoft fournit certaines fonctions utiles pour détecter et corriger les fuites de mémoire.

Je voudrais commencer par cette série d'articles: http://msdn.microsoft.com/en-us/library/x98tx3cf(SV.71).aspx

Voici le résumé de ces articles. Tout d'abord, inclure ces en-têtes:

#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

Ensuite, vous devez appeler quand le programme des sorties:

_CrtDumpMemoryLeaks();

Alternativement, si votre programme n'a pas de sortie dans le même endroit tout le temps, vous pouvez appeler cela au début de votre programme:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Maintenant, quand le programme s'arrête toutes les attributions qui ne sont pas libres aimerais sera imprimé dans la Fenêtre de Sortie avec le dossier de l'attribution et de la répartition de l'événement.

Cette stratégie fonctionne pour la plupart des programmes. Toutefois, il devient difficile, voire impossible dans certains cas. À l'aide de bibliothèques tierces qui n'certains d'initialisation au démarrage peut causer d'autres objets apparaissent dans le vidage de la mémoire et peut faire la traque de vos fuites difficiles. Aussi, si l'un de vos classes ont des membres avec le même nom qu'une partie de la mémoire de l'allocation des routines( comme malloc ), le CRT de débogage macros va causer des problèmes.

Il existe d'autres techniques expliquées dans la MSDN lien référencé ci-dessus qui pourraient être utilisés aussi bien.

Answer 3

En C ++: utilisez RAII. Les pointeurs intelligents tels que std :: auto_ptr, boost :: shared_ptr, boost :: scoped_ptr et boost :: faiblesse_ptr sont vos amis.

Answer 4

En tant que Développeur C++, voici simplement quelques lignes directrices:

1. Utiliser des pointeurs seulement quand c'est absolument nécessaire
2. Si vous avez besoin d'un pointeur, de façon optimale si un SmartPointer est une possibilité
3. L'utilisation de la connaissance Créateur de modèle.

Comme pour la détection de fuites de mémoire personnellement, j'ai toujours utilisé Visual Détecteur de Fuite et trouve que c'est très utile.

Answer 5

J'ai été en utilisant DevStudio depuis de trop nombreuses années maintenant, et cela m'étonne toujours du nombre de programmeurs ne savent pas à propos de la mémoire des outils d'analyse qui sont disponibles dans le débogage de l'exécution des bibliothèques. Voici quelques liens pour commencer:

Le suivi des Tas de Demandes d'Allocation - en particulier la section Unique de Demande d'Allocation des Numéros de

_CrtSetDbgFlag

_CrtSetBreakAlloc

Bien sûr, si vous ne l'utilisez pas DevStudio alors ce ne sera pas particulièrement utile.