In Visual Studio C ++, quali sono le rappresentazioni di allocazione della memoria?

Question

In Visual Studio, abbiamo avuto tutti " baadf00d " ;, abbiamo visto " CC " e "CD" durante l'ispezione delle variabili nel debugger in C ++ durante il runtime.

Da quello che ho capito, "CC" è in modalità DEBUG solo per indicare quando una memoria è stata nuova () o alloc () e unitilializzata. Mentre " CD " rappresenta la memoria eliminata o libera. Ho visto solo " baadf00d " nella build RELEASE (ma potrei sbagliarmi).

Di tanto in tanto ci troviamo in una situazione di contrasto di perdite di memoria, buffer overflow, ecc. e questo tipo di informazioni sono utili.

Qualcuno sarebbe abbastanza gentile da indicare quando e in quali modalità la memoria è impostata su schemi di byte riconoscibili a scopo di debug?

Answer 1

Questo link contiene ulteriori informazioni:

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

In realtà ci sono molte informazioni utili aggiunte alle allocazioni di debug. Questa tabella è più completa:

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

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

Riguardo in particolare a 0xCC e 0xCD , si tratta di reliquie di Intel 8088 / 8086 istruzioni per i processori arretrate negli anni '80. 0xCC è un caso speciale di interruzione software opcode INT 0xCD . La speciale versione a byte singolo 0xCC consente a un programma di generare interrupt 3 .

Sebbene i numeri di interruzione software siano, in linea di principio, arbitrari, INT 3 è stato tradizionalmente utilizzato per la interruzione del debugger o breakpoint , una convenzione che rimane ancora oggi. Ogni volta che viene avviato un debugger, viene installato un gestore di interrupt per INT 3 in modo tale che quando viene eseguito quel codice operativo verrà attivato il debugger. In genere mette in pausa la programmazione attualmente in esecuzione e mostra un prompt interattivo.

Normalmente, il codice operativo x86 INT è di due byte: 0xCD seguito dal numero di interruzione desiderato compreso tra 0 e 255. Ora sebbene sia possibile emettere 0xCD 0x03 per INT 3 , Intel ha deciso di aggiungere una versione speciale-- 0xCC senza byte aggiuntivo, perché un Il codice operativo deve essere solo un byte per funzionare come un "byte di riempimento" affidabile per la memoria non utilizzata.

Il punto qui è consentire un grazioso recupero se il processore salta erroneamente nella memoria che non contiene alcuna istruzione prevista . Le istruzioni multi-byte non sono adatte a questo scopo poiché un salto errato potrebbe atterrare a qualsiasi possibile offset di byte dove dovrebbe continuare con un flusso di istruzioni correttamente formato.

Ovviamente, i codici operativi a un byte funzionano in modo banale per questo, ma possono esserci anche eccezioni bizzarre: ad esempio, considerando la sequenza di riempimento 0xCDCDCDCD (menzionata anche in questa pagina), possiamo vedere che è abbastanza affidabile poiché non importa dove puntatore istruzioni atterra (tranne forse l'ultimo byte riempito), la CPU può riprendere l'esecuzione di un'istruzione a due byte x86 valida CD CD , in questo caso per la generazione dell'interrupt software 205 (0xCD).

Weirder ancora, mentre CD CC CD CC è interpretabile al 100% - dando INT 3 o INT 204 - la sequenza < codice> CC CD CC CD è meno affidabile, solo il 75% come mostrato, ma generalmente il 99,99% quando ripetuto come riempitivo di memoria di dimensioni int.

_{Riferimento assembler macro , 1987}