Suivi des demandes d'allocation du tas

Mise à jour : novembre 2007

Cette rubrique s'applique à :

Édition	Visual Basic	C#	C++	Web Developer
Express			Natif uniquement
Standard			Natif uniquement
Pro et Team			Natif uniquement

Légende du tableau :

	Applicable
	Non applicable
	Commande ou commandes masquées par défaut.

La localisation du nom du fichier source et du numéro de ligne où une macro d'assertion ou de création de rapports est exécutée facilite souvent l'identification de la cause d'un problème. Dans le cas des fonctions d'allocation du tas, cela est moins sûr. Alors que les macros peuvent être insérées en de nombreux points appropriés dans l'arborescence logique d'une application, une allocation est souvent enfouie dans une routine spéciale appelée à partir de nombreux emplacements distincts et à différentes heures. En général, la question n'est pas de savoir quelle ligne de code a effectué une mauvaise allocation, mais plutôt quelle est, parmi les milliers d'allocations effectuées par cette ligne de code, celle qui était incorrecte, et pour quelle raison elle l'était.

Numéros de demande d'allocation uniques et _crtBreakAlloc

Le moyen le plus simple d'identifier précisément l'appel d'allocation du tas qui s'est avéré incorrect consiste à exploiter le numéro de demande d'allocation unique associé à chaque bloc dans le tas de débogage. Lorsque les informations sur un bloc sont reportées par l'une des fonctions de dump, ce numéro de demande d'allocation est placé entre accolades (par exemple, « {36} »).

Une fois que vous connaissez le numéro de demande d'allocation d'un bloc alloué de façon incorrecte, vous pouvez passer ce numéro à _CrtSetBreakAlloc pour créer un point d'arrêt. L'exécution sera interrompue juste avant l'allocation du bloc et vous pourrez effectuer des recherches rétroactives pour déterminer quelle routine est à l'origine de l'appel incorrect. Pour éviter une recompilation, vous pouvez effectuer la même chose dans le débogueur en réglant _crtBreakAlloc sur le numéro de la demande d'allocation qui vous intéresse.

Création de versions Debug de vos routines d'allocation

Une approche un peu plus complexe consiste à créer des versions Debug de vos propres routines d'allocation, comparables aux versions _dbg des fonctions d'allocation du tas. Vous pouvez ensuite passer les arguments fichier source et numéro de ligne aux routines d'allocation du tas sous-jacentes : vous verrez alors immédiatement à quel endroit une allocation incorrecte a eu lieu.

Supposons, par exemple, que votre application contient une routine couramment utilisée, similaire à la suivante :

int addNewRecord(struct RecStruct * prevRecord,
                 int recType, int recAccess)
{
    // ...code omitted through actual allocation... 
    if ((newRec = malloc(recSize)) == NULL)
    // ... rest of routine omitted too ... 
}

Dans un fichier d'en-tête, vous pourriez ajouter un code semblable au suivant :

#ifdef _DEBUG
#define  addNewRecord(p, t, a) \
            addNewRecord(p, t, a, __FILE__, __LINE__)
#endif

Vous pourriez ensuite changer l'allocation dans votre routine de création d'enregistrements de la façon suivante :

int addNewRecord(struct RecStruct *prevRecord,
                int recType, int recAccess
#ifdef _DEBUG
               , const char *srcFile, int srcLine
#endif
    )
{
    /* ... code omitted through actual allocation ... */
    if ((newRec = _malloc_dbg(recSize, _NORMAL_BLOCK,
            srcFile, scrLine)) == NULL)
    /* ... rest of routine omitted too ... */
}

Dorénavant, le nom du fichier source et le numéro de ligne où addNewRecord a été appelé seront stockés à l'intérieur de chaque bloc résultant alloué dans le tas de débogage et seront reportés lors de l'examen de ce bloc.

Voir aussi

Autres ressources

Tas de débogage CRT