Partager via


Interprétation d'un dump d'objets

Cette rubrique s'applique à :

Édition

Visual Basic

C#

F#

C++

Web Developer

Express

La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas

Natif uniquement

La rubrique ne s'applique pas

Pro, Premium et Ultimate

La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas

Natif uniquement

La rubrique ne s'applique pas

Examinons ce dump d'objets plus en détail :

{5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long
{4} strcore.cpp(80) : non-object block at $00A751F8, 5 bytes long
{3} strcore.cpp(80) : non-object block at $00A751D6, 6 bytes long
{2} a CPerson at $51A4

Last Name: Smith
First Name: Alan
Phone #: 581-0215

{1} strcore.cpp(80) : non-object block at $00A7516E, 25 bytes long

Le programme qui a généré ce dump n'avait que deux allocations explicites : une sur la pile, l'autre sur le tas :

// Do your memory allocations and deallocations.
CString s("This is a frame variable");
// The next object is a heap object.
CPerson* p = new CPerson( "Smith", "Alan", "581-0215" );

Le constructeur CPerson prend trois arguments qui correspondent à des pointeurs vers char, utilisés pour initialiser les variables membres CString. Dans le dump mémoire, vous pouvez voir l'objet CPerson avec trois blocs non-objets (3, 4 et 5). Ces derniers contiennent les caractères pour les variables membres CString et ne seront pas supprimés lorsque le destructeur d'objet CPerson sera appelé.

Le bloc numéro 2 est l'objet CPerson lui-même. $51A4 représente l'adresse du bloc, laquelle est suivie du contenu de l'objet, qui a été sorti par CPerson::Dump lorsque ce dernier a été appelé par DumpAllObjectsSince.

Vous pouvez deviner que le bloc numéro 1 est associé à la variable frame CString en raison de son numéro de séquence et de sa taille, qui correspond au nombre de caractères dans la CString variable. Les variables allouées sur le frame sont automatiquement désallouées lorsque le frame est hors de portée.

Variables frame

En général, vous n'avez pas à vous soucier des objets de tas associés à des variables frame, car ils sont automatiquement désalloués lorsque celles-ci sont hors de portée. Afin d'éviter tout encombrement dans les dumps des diagnostics de la mémoire, vous devez positionner vos appels à Checkpoint de telle sorte qu'ils se trouvent hors de la portée des variables frame. Par exemple, placez des parenthèses de portée autour du code d'allocation, comme indiqué ci-après :

oldMemState.Checkpoint();
{
    // Do your memory allocations and deallocations ...
    CString s("This is a frame variable");
    // The next object is a heap object.
    CPerson* p = new CPerson( "Smith", "Alan", "581-0215" );
}
newMemState.Checkpoint();

Une fois la portée mise entre parenthèses, le dump mémoire, pour cet exemple, se présente de la façon suivante :

Dumping objects ->

{5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long
{4} strcore.cpp(80) : non-object block at $00A751F8, 5 bytes long
{3} strcore.cpp(80) : non-object block at $00A751D6, 6 bytes long
{2} a CPerson at $51A4

Last Name: Smith
First Name: Alan
Phone #: 581-0215

Allocations non-objets

Comme vous pouvez le remarquer, certaines allocations sont des objets (tel CPerson), d'autres sont des allocations non-objets. " Les « allocations non-objets » sont des allocations pour des objets non dérivés de CObject ou des allocations de types C primitifs, tels que char, int, ou long. Si la classe dérivée CObject - alloue de l'espace supplémentaire (pour les mémoires tampons internes, par exemple), ces objets afficheront à la fois des allocations objets et non-objets.

Prévention des fuites de mémoire

Notez que, dans le code ci-dessus, le bloc de mémoire associé à la variable frame CString a été désalloué automatiquement et n'apparaît pas comme une fuite de mémoire. La désallocation automatique associée aux règles de portée se charge de la plupart des fuites de mémoire associées aux variables frame.

Dans le cas des objets alloués sur le tas, cependant, vous devez supprimer l'objet de façon explicite pour éviter une fuite de mémoire. Pour nettoyer la dernière fuite de mémoire dans l'exemple précédent, supprimez l'objet CPerson alloué sur le tas, comme indiqué ci-après :

{
    // Do your memory allocations and deallocations.
    CString s("This is a frame variable");
    // The next object is a heap object.
    CPerson* p = new CPerson( "Smith", "Alan", "581-0215" );
    delete p;
}

Voir aussi

Référence

_CrtMemDumpAllObjectsSince

Concepts

Dumps d'objets

Autres ressources

Détection de fuite de mémoire dans MFC