Когда и почему компилятор инициализирует память до 0xCD, 0xDD и т. Д. В malloc / free / new / delete?

Я знаю, что компилятор иногда инициализирует память определенными шаблонами, такими как 0xCDи 0xDD. Я хочу знать, когда и почему это происходит.

когда

Это специфично для используемого компилятора?

Так поступают malloc/newи free/deleteработают в этом отношении?

Это зависит от платформы?

Произойдет ли это в других операционных системах, например Linuxили VxWorks?

Зачем

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

Можете ли вы привести какие-либо практические примеры того, насколько полезна эта инициализация?

Я помню, как читал что-то (возможно, в Code Complete 2), в котором говорилось, что хорошо инициализировать память по известному шаблону при ее выделении, и некоторые шаблоны будут запускать прерывания, в Win32результате чего в отладчике будут отображаться исключения.

Насколько это портативно?

Краткое изложение того, что компиляторы Microsoft используют для различных битов незарегистрированной / неинициализированной памяти при компиляции для режима отладки (поддержка может зависеть от версии компилятора):

Value     Name           Description 
------   --------        -------------------------
0xCD     Clean Memory    Allocated memory via malloc or new but never 
                         written by the application. 

0xDD     Dead Memory     Memory that has been released with delete or free. 
                         It is used to detect writing through dangling pointers. 

0xED or  Aligned Fence   'No man's land' for aligned allocations. Using a 
0xBD                     different value here than 0xFD allows the runtime
                         to detect not only writing outside the allocation,
                         but to also identify mixing alignment-specific
                         allocation/deallocation routines with the regular
                         ones.

0xFD     Fence Memory    Also known as "no mans land." This is used to wrap 
                         the allocated memory (surrounding it with a fence) 
                         and is used to detect indexing arrays out of 
                         bounds or other accesses (especially writes) past
                         the end (or start) of an allocated block.

0xFD or  Buffer slack    Used to fill slack space in some memory buffers 
0xFE                     (unused parts of `std::string` or the user buffer 
                         passed to `fread()`). 0xFD is used in VS 2005 (maybe 
                         some prior versions, too), 0xFE is used in VS 2008 
                         and later.

0xCC                     When the code is compiled with the /GZ option,
                         uninitialized variables are automatically assigned 
                         to this value (at byte level). 


// the following magic values are done by the OS, not the C runtime:

0xAB  (Allocated Block?) Memory allocated by LocalAlloc(). 

0xBAADF00D Bad Food      Memory allocated by LocalAlloc() with LMEM_FIXED,but 
                         not yet written to. 

0xFEEEFEEE               OS fill heap memory, which was marked for usage, 
                         but wasn't allocated by HeapAlloc() or LocalAlloc(). 
                         Or that memory just has been freed by HeapFree(). 

Отказ от ответственности: таблица взята из некоторых заметок, которые я валял - они могут быть не на 100% правильными (или связными).

Многие из этих значений определены в vc / crt / src / dbgheap.c:

/*
 * The following values are non-zero, constant, odd, large, and atypical
 *      Non-zero values help find bugs assuming zero filled data.
 *      Constant values are good, so that memory filling is deterministic
 *          (to help make bugs reproducible).  Of course, it is bad if
 *          the constant filling of weird values masks a bug.
 *      Mathematically odd numbers are good for finding bugs assuming a cleared
 *          lower bit.
 *      Large numbers (byte values at least) are less typical and are good
 *          at finding bad addresses.
 *      Atypical values (i.e. not too often) are good since they typically
 *          cause early detection in code.
 *      For the case of no man's land and free blocks, if you store to any
 *          of these locations, the memory integrity checker will detect it.
 *
 *      _bAlignLandFill has been changed from 0xBD to 0xED, to ensure that
 *      4 bytes of that (0xEDEDEDED) would give an inaccessible address under 3gb.
 */

static unsigned char _bNoMansLandFill = 0xFD;   /* fill no-man's land with this */
static unsigned char _bAlignLandFill  = 0xED;   /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill   = 0xDD;   /* fill free objects with this */
static unsigned char _bCleanLandFill  = 0xCD;   /* fill new objects with this */

Также есть несколько случаев, когда среда выполнения отладки заполняет буферы (или части буферов) известным значением, например, «свободным» пространством в std::stringраспределении или переданным буфером fread(). В этих случаях используется значение с именем _SECURECRT_FILL_BUFFER_PATTERN(определенным в crtdefs.h). Я не уверен, когда именно он был представлен, но это было во время отладки, по крайней мере, в VS 2005 (VC ++ 8).

Первоначально значение, используемое для заполнения этих буферов, было 0xFDтаким же, как и для нейтральной земли. Однако в VS 2008 (VC ++ 9) значение было изменено на 0xFE. Я предполагаю, что это потому, что могут быть ситуации, когда операция заполнения будет выполняться за пределами конца буфера, например, если вызывающий объект передал размер буфера, который был слишком большим для fread(). В этом случае значение 0xFDможет не инициировать обнаружение этого переполнения, поскольку, если размер буфера был бы слишком большим только на единицу, значение заполнения было бы таким же, как значение нейтральной земли, используемое для инициализации этой канарейки. Отсутствие изменений на нейтральной территории означает, что вторжение не будет замечено.

Таким образом, значение заполнения было изменено в VS 2008, чтобы такой случай изменил нейтральную канарейку, что привело к обнаружению проблемы средой выполнения.

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

Одно приятное свойство значения заполнения 0xCCCCCCCC заключается в том, что в сборке x86 код операции 0xCC - это код операции int3 , который является программным прерыванием точки останова. Итак, если вы когда-нибудь попытаетесь выполнить код в неинициализированной памяти, которая была заполнена этим значением заполнения, вы немедленно попадете в точку останова, и операционная система позволит вам подключить отладчик (или убить процесс).

Это зависит от компилятора и ОС, Visual Studio устанавливает для разных типов памяти разные значения, так что в отладчике вы можете легко увидеть, перешли ли вы в некорректную память, фиксированный массив или неинициализированный объект. Кто-нибудь опубликует подробности, пока я буду гуглить ...

http://msdn.microsoft.com/en-us/library/974tc9t1.aspx

Это не ОС - это компилятор. Вы также можете изменить поведение - см. Внизу этого сообщения.

Microsoft Visual Studio генерирует (в режиме отладки) двоичный файл, который предварительно заполняет стековую память с помощью 0xCC. Он также вставляет пробел между каждым кадром стека, чтобы обнаруживать переполнение буфера. Вот очень простой пример того, где это полезно (на практике Visual Studio обнаружит эту проблему и выдаст предупреждение):

...
   bool error; // uninitialised value
   if(something)
   {
      error = true;
   }
   return error;

Если Visual Studio не выполняет предварительную инициализацию переменных до известного значения, эту ошибку может быть трудно найти. С предварительно инициализированными переменными (или, скорее, предварительно инициализированной стековой памятью) проблема воспроизводится при каждом запуске.

Однако есть небольшая проблема. Visual Studio использует значение ИСТИНА - все, кроме 0, будет. На самом деле вполне вероятно, что когда вы запускаете свой код в режиме Release, унифицированные переменные могут быть выделены части памяти стека, которая содержит 0, что означает, что у вас может быть ошибка модульной переменной, которая проявляется только в режиме Release.

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

Это специфично для используемого компилятора?

На самом деле, это почти всегда функция библиотеки времени выполнения (например, библиотеки времени выполнения C). Среда выполнения обычно сильно коррелирует с компилятором, но есть некоторые комбинации, которые вы можете поменять местами.

Я считаю, что в Windows куча отладки (HeapAlloc и т. Д.) Также использует специальные шаблоны заполнения, которые отличаются от тех, которые исходят от реализации malloc и free в библиотеке времени выполнения отладки C. Так что это также может быть функция ОС, но в большинстве случаев это просто библиотека времени выполнения языка.

Работают ли malloc / new и free / delete одинаково в этом отношении?

Часть управления памятью new и delete обычно реализуется с помощью malloc и free, поэтому память, выделенная с помощью new и delete, обычно имеет одни и те же функции.

Это зависит от платформы?

Детали зависят от времени выполнения. Фактические используемые значения часто выбираются не только так, чтобы они выглядели необычно и очевидно при просмотре шестнадцатеричного дампа, но и для того, чтобы иметь определенные свойства, которые могут использовать преимущества функций процессора. Например, часто используются нечетные значения, поскольку они могут вызвать ошибку выравнивания. Используются большие значения (в отличие от 0), потому что они вызывают неожиданные задержки, если вы перейдете к неинициализированному счетчику. На x86 0xCC - это int 3инструкция, поэтому, если вы запустите неинициализированную память, она перехватится.

Произойдет ли это в других операционных системах, таких как Linux или VxWorks?

Это в основном зависит от используемой библиотеки времени выполнения.

Можете ли вы привести какие-либо практические примеры того, насколько полезна эта инициализация?

Некоторые из них я перечислил выше. Значения обычно выбираются для увеличения вероятности того, что произойдет что-то необычное, если вы сделаете что-то с недопустимыми частями памяти: длинные задержки, ловушки, ошибки выравнивания и т. Д. Менеджеры кучи также иногда используют специальные значения заполнения для промежутков между выделениями. Если эти шаблоны когда-либо изменятся, он знает, что где-то была неправильная запись (например, переполнение буфера).

Я помню, что читал что-то (возможно, в Code Complete 2), что хорошо инициализировать память по известному шаблону при ее распределении, и некоторые шаблоны будут запускать прерывания в Win32, что приведет к отображению исключений в отладчике.

Насколько это портативно?

Написание Solid Code (и, возможно, Code Complete ) рассказывает о вещах, которые следует учитывать при выборе шаблонов заливки. Я упомянул некоторые из них здесь, и статья в Википедии о Magic Number (программировании) также суммирует их. Некоторые приемы зависят от специфики используемого вами процессора (например, требует ли он выровненных операций чтения и записи и какие значения соответствуют инструкциям, которые будут перехватываться). Другие приемы, такие как использование больших значений и необычных значений, которые выделяются в дампе памяти, более переносимы.

В этой статье описываются необычные битовые шаблоны памяти и различные методы, которые можно использовать, если вы столкнетесь с этими значениями.

Очевидная причина "почему" в том, что предположим, что у вас есть такой класс:

class Foo
{
public:
    void SomeFunction()
    {
        cout << _obj->value << endl;
    }

private:
    SomeObject *_obj;
}

И затем вы создаете экземпляр a Fooи вызываете SomeFunction, он даст нарушение доступа, пытаясь прочитать0xCDCDCDCD . Это означает, что вы забыли что-то инициализировать. Это «почему». Если нет, то указатель мог быть выровнен с какой-то другой памятью, и его было бы труднее отлаживать. Это просто сообщает вам причину нарушения прав доступа. Обратите внимание, что этот случай был довольно простым, но в более крупном классе легко допустить эту ошибку.

AFAIK, это работает только в компиляторе Visual Studio в режиме отладки (в отличие от выпуска)

Легко увидеть, что память изменилась по сравнению с начальным начальным значением, как правило, во время отладки, но иногда и для кода выпуска, поскольку вы можете присоединять отладчики к процессу во время его работы.

Это не просто память, многие отладчики устанавливают для содержимого регистров контрольное значение при запуске процесса (некоторые версии AIX устанавливают некоторые регистры, 0xdeadbeefчто несколько забавно).

В компиляторе IBM XLC есть опция «initauto», которая присваивает автоматическим переменным указанное вами значение. Для отладочных сборок я использовал следующее:

-Wc,'initauto(deadbeef,word)'

Если бы я посмотрел на хранилище неинициализированной переменной, было бы установлено значение 0xdeadbeef