En Visual Studio C++, ¿cuáles son las representaciones de asignación de memoria?

Question

En Visual Studio, todos hemos tenido "baadf00d", hemos visto "CC" y "CD" al inspeccionar variables en el depurador en C++ durante el tiempo de ejecución.

Por lo que tengo entendido, "CC" está en modo DEBUG solo para indicar cuando una memoria ha sido nueva () o alloc () y unilializada.Mientras que "CD" representa memoria eliminada o liberada.Sólo he visto "baadf00d" en la versión RELEASE (pero puede que me equivoque).

De vez en cuando, nos encontramos en una situación en la que tenemos que abordar pérdidas de memoria, desbordamientos de búfer, etc., y este tipo de información resulta útil.

¿Alguien sería tan amable de señalar cuándo y en qué modos la memoria se configura con patrones de bytes reconocibles para fines de depuración?

Answer 1

Este enlace tiene más información:

http://en.wikipedia.org/wiki/Magic_number_(programación)

* 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

En realidad, se agrega bastante información útil a las asignaciones de depuración.Esta tabla es más completa:

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

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

Acerca de 0xCC y 0xCD en particular, estas son reliquias de la Intel 8088/8086 instrucción del procesador ambientada en la década de 1980. 0xCC es un caso especial del interrupción de software código de operación INT 0xCD.La versión especial de un solo byte 0xCC permite que un programa genere interrumpir 3.

Aunque los números de interrupciones de software son, en principio, arbitrarios, INT 3 fue utilizado tradicionalmente para el pausa del depurador o punto de interrupción función, convención que se mantiene hasta el día de hoy.Cada vez que se inicia un depurador, instala un controlador de interrupciones para INT 3 de modo que cuando se ejecute ese código de operación, se activará el depurador.Por lo general, pausará la programación que se está ejecutando actualmente y mostrará un mensaje interactivo.

Normalmente, el x86 INT El código de operación es de dos bytes: 0xCD seguido del número de interrupción deseado del 0 al 255.Ahora bien, aunque podrías emitir 0xCD 0x03 para INT 3, Intel decidió agregar una versión especial:0xCC sin bytes adicionales, porque un código de operación debe tener solo un byte para funcionar como un 'byte de relleno' confiable para la memoria no utilizada.

El punto aquí es permitir una recuperación elegante. si el procesador salta por error a una memoria que no contiene las instrucciones previstas.Las instrucciones multibyte no son adecuadas para este propósito ya que un salto erróneo podría aterrizar en cualquier posible desplazamiento de bytes donde tendría que continuar con un flujo de instrucciones formado correctamente.

Obviamente, los códigos de operación de un byte funcionan de manera trivial para esto, pero también puede haber excepciones extravagantes:por ejemplo, considerando la secuencia de llenado 0xCDCDCDCD (también mencionado en esta página), podemos ver que es bastante confiable ya que no importa dónde esté puntero de instrucción tierras (excepto tal vez el último byte llenado), la CPU puede reanudar la ejecución de un dos bytes instrucción x86 CD CD, en este caso para generar la interrupción de software 205 (0xCD).

Más extraño aún, mientras que CD CC CD CC es 100% interpretable, ya sea INT 3 o INT 204--la secuencia CC CD CC CD es menos confiable, solo el 75% como se muestra, pero generalmente el 99,99% cuando se repite como un relleno de memoria de tamaño int.

_{Referencia del ensamblador de macros, 1987}