In Visual Studio C ++, was sind die Speicherzuweisung Darstellungen?

Question

In Visual Studio, wir hatten alle "baadf00d", hat gesehen, "CC" gesehen und "CD", wenn Variablen im Debugger in C ++ während der Laufzeit inspizieren.

Von dem, was ich verstehe, „CC“ im Debug-Modus ist nur, um anzuzeigen, wenn ein Speicher neu ist () oder alloc () und unitilialized. Während die „CD“ steht für delete'd oder free'd Speicher. Ich habe nur "baadf00d" in Release-Build zu sehen (aber ich kann falsch sein).

Einmal in einer Weile erhalten wir in eine Situation, Speicherlecks Tackern, Pufferüberläufe usw., und diese Art von Informationen ist praktisch.

Wäre jemand so freundlich darauf hinweisen, wann und in welcher Modi den Speicher für das Debuggen Zweck zu erkennen Byte-Muster werden?

Answer 1

Dieser Link hat mehr Informationen:

http://en.wikipedia.org/wiki/Magic_number_(programming)

* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
* 0xBAADF00D : Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
* 0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
* 0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
* 0xCCCCCCCC : Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory
* 0xDDDDDDDD : Used by Microsoft's C++ debugging heap to mark freed heap memory
* 0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
* 0xFDFDFDFD : Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft's HeapFree() to mark freed heap memory

Answer 2

Es gibt tatsächlich einiges an nützlichen Informationen zu Debug-Zuweisungen hinzugefügt. Diese Tabelle ist vollständiger:

http://www.nobugs.org/developer/win32/debug_crt_heap. html # Tabelle

Address  Offset After HeapAlloc() After malloc() During free() After HeapFree() Comments
0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info
0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info
0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block (allocated earlier in time)
0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block (allocated later in time)
0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc() call
0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc() call
0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc()
0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type (0=Freed, 1=Normal, 2=CRT use, etc)
0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request #, increases from 0
0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x00321000  +0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321004  +4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321008  +8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x0032100C  +12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes
0x00321010  +16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321014  +20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321018  +24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping
0x0032101C  +28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping
0x00321020  +32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping
0x00321024  +36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping
0x00321028  +40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping
0x0032102C  +44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping

Answer 3

In Bezug auf 0xCC und 0xCD insbesondere das sind Relikte aus der 8088 / 8086 Prozessorbefehl in den 1980er Jahren zurück. 0xCC ist ein Spezialfall des Software-Interrupt Opcode INT 0xCD. Die spezielle Single-Byte-Version 0xCC ermöglicht ein Programm zu erzeugen Interrupt 3 .

Obwohl Software-Interrupt-Nummern sind im Prinzip beliebig, INT 3 traditionell für die Debugger Pause wurden verwendet, oder Breakpoint -Funktion, eine Konvention, die bis zum heutigen Tag. Jedes Mal, wenn ein Debugger gestartet wird, installiert er einen Interrupt-Handler für INT 3 so dass, wenn das Opcode der Debugger ausgelöst wird ausgeführt. Typischerweise wird es die aktuell laufende Programmierung und zeigt eine interaktive Eingabeaufforderung pausieren.

Normalerweise ist der x86-Opcode INT zwei Bytes 0xCD durch die gewünschte Unterbrechungsnummer von 0-255 gefolgt. Nun, obwohl Sie 0xCD 0x03 für INT 3 ausgeben konnte, entschied sich Intel eine spezielle Version hinzufügen - 0xCC ohne zusätzliches Byte - weil ein Opcode nur ein Byte, um als zuverlässiger ‚Byte füllen‘ funktionieren muss für nicht genutzte Speicher

hier Der Punkt ist für anmutige Erholung , wenn der Prozessor fälschlicherweise springt in dem Speicher zu ermöglichen, die keine beabsichtigten Anweisungen enthält . Multi-Byte-Befehle sind zu diesem Zweck nicht, da eine fehlerhaften Sprung geeignet an jedem möglichen Byte landen konnten versetzt, wo er mit einem korrekt gebildet Befehlsstrom fortzusetzen würde.

Offensichtlich Ein-Byte-Opcodes arbeiten trivialerweise für diese, aber auch skurrile Ausnahmen geben kann: zum Beispiel die Füllsequenz 0xCDCDCDCD Berücksichtigung (auch auf dieser Seite erwähnt), können wir sehen, dass es da keine Angelegenheit recht zuverlässig ist, wo die Befehlszeiger Länder (mit Ausnahme von vielleicht das letzten gefüllten Byte), das CPU wieder aufnehmen können, einen gültigen zwei-Byte x86-Befehl CD CD, in diesem Fall der Ausführung zum Erzeugen von Software-Interrupt 205 (0xCD).

Weirder noch, während CD CC CD CC ist 100% interpretierbar - geben entweder INT 3 oder INT 204 -. Die Sequenz CC CD CC CD ist weniger zuverlässig, nur 75%, wie gezeigt, aber in der Regel 99,99%, wenn sie als Int-sized Speicher Füllstoff wiederholt

_{Macro Assembler Referenz 1987}