Interpretation von Objektdumps
Aktualisiert: November 2007
Dieses Thema gilt für folgende Anwendungsbereiche:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
Nur "Systemeigen" |
|
Standard |
|
|
Nur "Systemeigen" |
|
Pro und Team |
|
|
Nur "Systemeigen" |
|
Tabellenlegende:
.gif) |
Vorhanden |
|
Nicht vorhanden |
.gif) |
Befehl oder Befehle, die standardmäßig ausgeblendet sind. |
Im Folgenden wird dieser Objektdump ausführlich erläutert:
{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
Das Programm, das diesen Dump generiert hat, verfügte nur über zwei explizite Reservierungen – eine für den Stapel und eine für den Heap:
// 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" );
Der CPerson-Konstruktor hat drei Argumente, die Zeiger auf char darstellen. Sie werden zur Initialisierung von CString-Membervariablen verwendet. Im Speicherdump ist das CPerson-Objekt zusammen mit drei Elementen, die keine Objekte darstellen (3, 4 und 5), aufgeführt. Diese enthalten die Zeichen für die CString-Membervariablen und werden beim Aufrufen des CPerson-Objektdestruktors nicht gelöscht.
Block Nummer 2 ist das CPerson-Objekt selbst. $51A4 stellt die Adresse des Speicherblocks dar. Es folgt der Objektinhalt, der durch CPerson::Dump ausgegeben wurde, sofern der Aufruf durch DumpAllObjectsSince erfolgt ist.
Block Nummer 1 kann der CString-Framevariablen zugeordnet werden. Dies lässt sich aus seiner Größe (entspricht der Anzahl der Zeichen in der CString-Variablen) und der Sequenznummer schließen. Reservierungen für Framevariablen werden automatisch freigegeben, wenn die Framevariable den Gültigkeitsbereich verlässt.
Framevariablen
Im Allgemeinen brauchen Sie sich um Heapobjekte, die mit Framevariablen verknüpft sind, nicht zu kümmern, da sie automatisch freigegeben werden, wenn die Framevariable den Gültigkeitsbereich verlässt. Um übersichtliche Dumps für die Speicherdiagnose zu erhalten, sollten Sie die Checkpoint-Aufrufe so positionieren, dass sie nicht im Gültigkeitsbereich von Framevariablen liegen. Schließen Sie beispielsweise den oben genannten Reservierungscode in Klammern ein, die den Gültigkeitsbereich darstellen. Siehe folgenden Code:
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();
Mit diesen Klammern sieht der Speicherdump für dieses Beispiel wie folgt aus:
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
Nicht-Objektreservierungen
Beachten Sie, dass einige Reservierungen sich auf Objekte (z. B. CPerson) und andere auf "Nicht-Objekte" beziehen. Bei "Nicht-Objektreservierungen" handelt es sich um Reservierungen für Objekte, die nicht von CObject abgeleitet wurden oder um Reservierungen primitiver C-Typen, z. B. char, int oder long. Wenn die von CObject-abgeleitete Klasse zusätzlichen Arbeitsspeicher reserviert, z. B. für interne Puffer, weisen die Objekte sowohl Objekt- als auch Nicht-Objektreservierungen auf.
Verhindern von Speicherverlusten
Im obigen Code sehen Sie, dass der mit der CString-Framevariablen verknüpfte Speicherblock automatisch freigegeben wurde und nicht als Speicherverlust angezeigt wird. Die automatische Freigabe aufgrund von Gültigkeitsbereichsregeln verhindert normalerweise Speicherverluste in Zusammenhang mit Framevariablen.
Objekte, für die Speicher auf dem Heap reserviert wird, sollten Sie jedoch explizit löschen, um Speicherverluste zu verhindern. Um den letzten Speicherverlust im oben stehenden Beispiel zu bereinigen, können Sie das CPerson-Objekt, für das Heapspeicher reserviert wurde, wie folgt löschen:
{
// 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;
}