Interprétation d'un dump d'objets
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. |
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;
}