В Visual Studio С++, каковы представления распределения памяти?
В Visual Studio у нас все были "baadf00d", которые видели "CC" и "CD" при проверке переменных в отладчике на С++ во время выполнения.
Из того, что я понимаю, "CC" находится в режиме DEBUG только для указания, когда память была новой() или alloc() и унифицирована. В то время как "CD" представляет собой память delete'd или free'd. Я видел только "baadf00d" в сборке RELEASE (но я могу ошибаться).
Время от времени мы сталкиваемся с ситуацией, связанной с утечками памяти, переполнением буфера и т.д., и такая информация пригодится.
Кто-нибудь будет достаточно любезен, чтобы указать, когда и в каких режимах память настроена на распознаваемые байтовые шаблоны для целей отладки?
Ответы
Ответ 1
У этой ссылки есть дополнительная информация:
http://en.wikipedia.org/wiki/Magic_number_(programming)
* 0xABABABAB : Used by Microsoft HeapAlloc() to mark "no man 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 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 C++ debugging runtime library to mark uninitialised stack memory
* 0xCDCDCDCD : Used by Microsoft C++ debugging runtime library to mark uninitialised heap memory
* 0xDDDDDDDD : Used by Microsoft 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 C++ debugging heap to mark "no man land" guard bytes before and after allocated heap memory
* 0xFEEEFEEE : Used by Microsoft HeapFree() to mark freed heap memory
Ответ 2
На самом деле довольно много полезной информации добавлено в отладочные распределения. Эта таблица более полная:
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
Ответ 3
Что касается 0xCC
и 0xCD
, в частности, эти реликвии от Intel 8088/8086 инструкция процессора, установленного в 1980 году. 0xCC
является частным случаем программного кода INT
0xCD
. Специальная однобайтная версия 0xCC
позволяет программе генерировать прерывание 3.
Несмотря на то, что номера программных прерываний в принципе произвольны, INT 3
традиционно используется для функции отладки или функции останова, которая остается до сих пор. Всякий раз, когда запускается отладчик, он устанавливает обработчик прерываний для INT 3
таким образом, что при выполнении этого кода операции отладчик будет запущен. Обычно он приостанавливает текущее программирование и отображает интерактивное приглашение.
Обычно код операции x86 INT
имеет два байта: 0xCD
за которым следует желаемый номер прерывания от 0 до 255. Теперь, хотя вы могли бы выпустить 0xCD 0x03
для INT 3
, Intel решила добавить специальный version-- 0xCC
без дополнительного байта - потому что опкод должен быть только один байт, чтобы функционировать в качестве надежного "заполнить байт" для неиспользуемой памяти.
Дело здесь в том, чтобы обеспечить изящное восстановление, если процессор ошибочно переходит в память, которая не содержит каких-либо намеченных инструкций. Многобайтовые инструкции не подходят для этой цели, так как ошибочный прыжок может приземляться при любом возможном смещении байта, где он должен будет продолжать правильно сформированный поток команд.
Очевидно, что однобайтные коды операций работают для этого тривиально, но также могут быть изворотливые исключения: например, учитывая последовательность заполнения 0xCDCDCDCD
(также упомянутую на этой странице), мы можем видеть, что она достаточно надежна, так как независимо от того, где указатель указателя приземляется (за исключением, возможно, последнего заполненного байта), CPU может возобновить выполнение действительного двухбайтового CD CD
инструкцией x86, в этом случае для генерации программного прерывания 205 (0xCD).
Еще более странно, в то время как CD CC CD CC
на 100% интерпретируемо - передача последовательности INT 3
или INT 204
--the CC CD CC CD
менее надежна, только 75%, как показано, но обычно 99,99% при повторении как int-size память.
Ссылка на ассемблер Macro, 1987