Когда и почему ОС инициализирует память к 0xCD, 0xDD, и т.д. на malloc/free/new/delete?
Все очень просто
Чтобы получить список всех необработанных файлов, используйте команду git status с опцией -u (--untracked-files)
git status -u
8 ответов
Быстрая сводка какой использование компиляторов 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.
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 detect 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 reproducable). 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 устанавливает различные виды памяти к различным значениям так, чтобы в отладчике можно было легко видеть, переполнились ли Вы в в malloced память, фиксированный массив или неинициализированный объект. Кто-то отправит детали, в то время как я гуглю их...
Это не ОС - это - компилятор. Можно изменить поведение также - посмотрите вниз нижнюю часть этого сообщения.
Microsoft Visual Studio генерирует (в Режиме отладки) двоичный файл, который предварительно заполняет стековую память 0xCC. Это также вставляет пространство между каждым стековым фреймом для обнаружения переполнения буфера. Очень простой пример того, где это полезно, здесь (в Visual Studio практики, определил бы эту проблему и выпустил бы предупреждение):
...
bool error; // uninitialised value
if(something)
{
error = true;
}
return error;
, Если бы Visual Studio не предварительно инициализировала переменные к известному значению, то эту ошибку могло потенциально быть трудно найти. С предварительно инициализированными переменными (или скорее предварительно инициализированная стековая память), проблема восстанавливаема на каждом выполнении.
Однако существует небольшая проблема. Использование Visual Studio значения является TRUE - что-либо кроме 0 было бы. На самом деле довольно вероятно, что при выполнении кода в режиме Release, что unitialised переменные могут быть выделены части стековой памяти, которая, оказывается, содержит 0, что означает, у Вас может быть unitialised ошибка в описании переменных, которая только проявляется в режиме Release.
, Который раздражал меня, таким образом, я записал сценарий для изменения значения перед заливкой, непосредственно редактируя двоичный файл, позволяя мне найти uninitalized переменные проблемы, которые только обнаруживаются, когда стек содержит нуль. Этот сценарий только изменяет предварительную заливку стека; я никогда не экспериментировал с предварительной заливкой "кучи", хотя это должно быть возможно. Мог бы включить редактирование DLL во время выполнения, не мог бы.
Очевидная причина, "почему" это, предполагает, что у Вас есть класс как это:
class Foo
{
public:
void SomeFunction()
{
cout << _obj->value << endl;
}
private:
SomeObject *_obj;
}
И затем Вы инстанцируете одного Foo и вызов SomeFunction, это даст нарушение прав доступа, пытающееся читать 0xCDCDCDCD. Это означает, что Вы забыли инициализировать что-то. Это "почему часть". В противном случае тогда указатель, возможно, выстроился в линию с некоторой другой памятью, и будет более трудно отладить. Это просто сообщает причину, что Вы получаете нарушение прав доступа. Обратите внимание, что этот случай был довольно прост, но в большем классе легко сделать ту ошибку.
AFAIK, это только работает над компилятором Visual Studio когда в режиме отладки (в противоположность выпуску)
Это должно легко видеть, что память изменилась от ее начального начального значения, обычно во время отладки, но иногда для кода выпуска также, так как можно присоединить отладчики к процессу, в то время как это работает.
Это не просто память также, много отладчиков установят содержание регистра на значение сигнальной метки, когда процесс запустится (некоторые версии AIX установят некоторые регистры на 0xdeadbeef, который является мягко юмористическим).
Компилятор XLC IBM имеет "initauto" опцию, которая присвоит автоматическим переменным значение, которое Вы определяете. Я использовал следующее для своих сборок отладки:
-Wc,'initauto(deadbeef,word)'
, Если бы я посмотрел на устройство хранения данных неинициализированной переменной, оно было бы установлено на 0xdeadbeef
В этой статье описываются необычные битовые шаблоны памяти и различные методы, которые можно использовать, если вы столкнетесь с этими значениями.