En Visual Studio C++, ¿cuáles son las representaciones de asignación de memoria?
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 entiendo, "CC" está en modo de DEPURACIÓN solo para indicar cuando una memoria ha sido new() o alloc() y unitilizada. Mientras que " CD " representa la memoria borrada o libre. Solo he visto "baadf00d" en RELEASE build (pero puedo estar equivocado).
De vez en cuando, nos encontramos con una situación de fugas de memoria, desbordamientos de búfer, etc. y este tipo de información es útil.
¿Alguien sería tan amable de señalar cuándo y en qué modos la memoria se establece en patrones de bytes reconocibles para fines de depuración?
3 answers
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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-08-12 14:51:39
En realidad hay un poco de información útil añadida 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
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-06-04 04:47:31
Con respecto a 0xCC
y 0xCD
en particular, estas son reliquias de la Intel 8088/8086 la instrucción del procesador se remonta a la década de 1980. 0xCC
es un caso especial de la interrupción del software opcode INT
0xCD
. La versión especial de un solo byte 0xCC
permite que un programa genere interrupción 3.
Aunque los números de interrupción de software son, en principio, arbitrarios, INT 3
se usó tradicionalmente para el depurador break or breakpoint function, a convention which remains to this day. Cada vez que se inicia un depurador, instala un manejador de interrupciones para INT 3
de modo que cuando se ejecuta ese código operativo, se activa el depurador. Por lo general, pausará la programación en ejecución y mostrará un mensaje interactivo.
Normalmente, el opcode x86 INT
es de dos bytes: 0xCD
seguido del número de interrupción deseado de 0 a 255. Ahora, aunque podría emitir 0xCD 0x03
para INT 3
, Intel decidió agregar una versión especial {0xCC
sin byte adicional because porque un opcode debe ser solo un byte para funcionar como un 'fill byte' confiable para la memoria no utilizada.
El punto aquí es permitir la recuperación agraciada si el procesador salta erróneamente a la memoria que no contiene ninguna instrucción intencionada. Las instrucciones Multi-byte no son adecuadas para este propósito, ya que un salto erróneo podría aterrizar en cualquier desplazamiento de byte posible donde tendría que continuar con un flujo de instrucciones correctamente formado.
Obviamente, los opcodes de un byte funcionan trivialmente para esto, pero también puede haber excepciones peculiares: por ejemplo, considerando la secuencia de relleno 0xCDCDCDCD
(también mencionada en esta página), podemos ver que es bastante confiable ya que no importa dónde aterrice el puntero de instrucción (excepto quizás el último byte llenado), la CPU puede reanudar la ejecución de un instrucción x86CD CD
, en este caso para generar software interrumpir 205 (0xCD).
Aún más extraño, mientras que CD CC CD CC
es 100% interpretable giving dando INT 3
o INT 204
the la secuencia CC CD CC CD
es menos confiable, solo 75% como se muestra, pero generalmente 99.99% cuando se repite como un relleno de memoria de tamaño int.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-02-04 13:49:56