Gestion de la mémoire et tas de débogage
Mise à jour : novembre 2007
Cette rubrique s'applique à :
Édition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
Natif uniquement |
|
Standard |
|
|
Natif uniquement |
|
Pro et Team |
|
|
Natif uniquement |
|
Légende du tableau :
.gif) |
Applicable |
|
Non applicable |
.gif) |
Commande ou commandes masquées par défaut. |
Le remplacement de la fin d'une mémoire tampon allouée et les fuites de mémoire (impossibilité de libérer les allocations lorsqu'elles sont devenues inutiles) comptent parmi les problèmes les plus courants et les plus complexes auxquels les programmeurs sont confrontés. Le tas de débogage fournit des outils puissants pour résoudre les problèmes d'allocation de mémoire de ce type.
Versions Debug des fonctions du tas
Les versions Debug des fonctions du tas appellent les versions standard ou de base utilisées dans les versions Release. Lorsque vous demandez un bloc de mémoire, le gestionnaire du tas de débogage alloue, à partir du tas de base, un bloc de mémoire légèrement plus grand que ce qui est demandé et retourne un pointeur vers votre partie de ce bloc. Par exemple, supposons que votre application contient l'appel : malloc( 10 ). Dans une version Release, malloc appellerait la routine d'allocation du tas de base, qui demanderait une allocation de 10 octets. Dans une version Debug, en revanche, malloc appellerait _malloc_dbg ; ce dernier appellerait à son tour la routine d'allocation du tas de base, qui demanderait une allocation de 10 octets, plus environ 36 octets de mémoire supplémentaire. Tous les blocs de mémoire résultants dans le tas de débogage sont connectés dans une seule liste liée, ordonnée en fonction du moment où ils ont été alloués.
La mémoire supplémentaire allouée par les routines du tas de débogage est utilisée pour les informations de comptabilité, pour les pointeurs qui lient les blocs de mémoire entre eux et pour les petites mémoires tampons de chaque côté de vos données dans le but d'intercepter les remplacements de la zone allouée.
Actuellement, la structure des en-têtes de bloc utilisée pour stocker les informations de comptabilité du tas de débogage est déclarée comme suit dans le fichier d'en-tête DBGINT.H :
typedef struct _CrtMemBlockHeader
{
// Pointer to the block allocated just before this one:
struct _CrtMemBlockHeader *pBlockHeaderNext;
// Pointer to the block allocated just after this one:
struct _CrtMemBlockHeader *pBlockHeaderPrev;
char *szFileName; // File name
int nLine; // Line number
size_t nDataSize; // Size of user block
int nBlockUse; // Type of block
long lRequest; // Allocation number
// Buffer just before (lower than) the user's memory:
unsigned char gap[nNoMansLandSize];
} _CrtMemBlockHeader;
/* In an actual memory block in the debug heap,
* this structure is followed by:
* unsigned char data[nDataSize];
* unsigned char anotherGap[nNoMansLandSize];
*/
Les mémoires tampons NoMansLand de chaque côté de la zone des données utilisateur du bloc ont actuellement une taille de 4 octets et contiennent une valeur d'octet connue, employée par les routines du tas de débogage pour vérifier que les limites du bloc de mémoire de l'utilisateur n'ont pas été écrasées. Le tas de débogage remplit également les nouveaux blocs de mémoire avec une valeur connue. Si vous choisissez de conserver les blocs libérés dans la liste liée du tas, comme indiqué ci-après, ces blocs libérés contiennent également une valeur connue. Actuellement, les valeurs d'octets réelles utilisées sont les suivantes :
NoMansLand (0xFD)
Les mémoires tampons « NoMansLand » de chaque côté de la mémoire utilisée par une application contiennent actuellement 0xFD.Blocs libérés (0xDD)
Les blocs libérés restés inutilisés dans la liste liée du tas de débogage lorsque l'indicateur _CRTDBG_DELAY_FREE_MEM_DF est défini contiennent actuellement 0xDD.Nouveaux objets (0xCD)
Les nouveaux objets contiennent 0xCD lorsqu'ils sont alloués.