В Visual Studio C ++, каковы представления распределения памяти?

Question

В Visual Studio у всех нас было "baadf00d", мы видели "CC" и "CD" при проверке переменных в отладчике в C ++ во время выполнения.

Из того, что я понимаю, "CC" находится в режиме отладки только для указания, когда память была новой () или alloc () и унитилизована. В то время как «CD» обозначает удаление или освобождение памяти. Я видел только baadf00d в RELEASE build (но могу ошибаться).

Время от времени мы попадаем в ситуацию с утечками памяти, переполнением буфера и т. Д., И такая информация оказывается полезной.

Будет ли кто-нибудь достаточно любезен, чтобы указать, когда и в каких режимах памяти установлены распознаваемые байтовые шаблоны для целей отладки?

Answer 1

Эта ссылка содержит больше информации:

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

На самом деле к отладочным выделениям добавлено довольно много полезной информации. Эта таблица является более полной:

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

Что касается 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 решила добавить специальную версию - 0xCC без дополнительного байта - потому что код операции должен быть только один байт, чтобы функционировать как надежный «байт заполнения» для неиспользуемой памяти.

Смысл здесь в том, чтобы обеспечить постепенное восстановление , если процессор ошибочно переходит в память, которая не содержит каких-либо предполагаемых инструкций . Многобайтовые инструкции не подходят для этой цели, так как ошибочный переход может привести к любому возможному смещению байта, где он должен был бы продолжаться с правильно сформированным потоком команд.

Очевидно, что однобайтовые коды операций работают для этого тривиально, но могут быть и причудливые исключения: например, рассматривая последовательность заполнения 0xCDCDCDCD (также упомянутую на этой странице), мы можем видеть, что она достаточно надежна, так как неважно где указатель указатель приземляется (за исключением возможно последний заполненный байт), CPU может возобновить выполнение действительной двухбайтовой x86 CD CD, в этом кейс для генерации программного прерывания 205 (0xCD).

Еще более странно, тогда как CD CC CD CC интерпретируется на 100% - давая либо INT 3, либо INT 204 - последовательность CC CD CC CD менее надежна, только 75%, как показано, но обычно 99,99% при повторении в виде заполнитель памяти int-size.

_{Справочник по макросам , 1987}