Неинициализированные блоки памяти в VC++

Когда вы создаете указатель, явно инициализируйте его NULL. Точно так же после delete. В зависимости от значения неинициализированных данных (за исключением нескольких конкретных случаев) возникают проблемы.

Вы можете избавить себя от множества головных болей, используя класс интеллектуальных указателей (например, boost::shared_ptr), который автоматически определяет, инициализирован ли указатель или нет.

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

Лучше всего просто привыкнуть ставить их на 0 в первую очередь, это всего лишь 2 дополнительных символа.

int *ptr=0;

Вы также можете использовать макрос NULL, который определяется как 0 (но не по умолчанию, поэтому будьте осторожны с несколькими определениями при включении таких вещей, как windows.h, и определении его самостоятельно!

Поведение VC++ не должно вызывать хаоса при любой проверке действительный, которую вы можете выполнить. Если вы видите 0xfeeefeee, значит, вы не записали в память (или освободили ее), поэтому вам все равно не следует читать из памяти.

Если вы выполняете сборку в режиме выпуска вместо режима отладки, среда выполнения вообще не заполняет неинициализированную память, но все равно не будет нулей. Однако вы должны зависеть от этого поведения нет - вы должны либо явно инициализировать память самостоятельно с помощью memset (), ZeroMemory () или SecureZeroMemory (), либо установить где-нибудь флаг, указывающий, что память еще не инициализирована. Чтение неинициализированной памяти приведет к неопределенному поведению.

Если вы читаете неинициализированную память, ваши чеки наверняка недействительны. Память освобождена. Возможно, он уже используется для чего-то другого. Вы не можете делать никаких предположений относительно содержимого неинициализированной памяти в C / C++.

Java (и, как я полагаю, C#) гарантирует, что выделенная память обнуляется перед использованием, и, конечно же, сборка мусора не позволяет вам вообще видеть освобожденную память. Но это не свойство кучи C, которая напрямую предоставляет доступ к памяти.

delete не несет ответственности за сброс всех указателей на объект на NULL. Также вы не должны изменять заполнение памяти по умолчанию для среды выполнения Windows DEBUG, и вы должны использовать что-то вроде boost::shared_ptr<> для указателей в любом случае.

Тем не менее, если вы действительно хотите выстрелить себе в ногу, вы можете.

Вы можете изменятьзаливка по умолчанию для окон Среда выполнения DEBUG, используя такой хук распределителя. Это будет работать только с выделенным объектом HEAP!

int main(int argc,char** arv)
{
  // Call first to register hook    
  _CrtSetAllocHook(&zero_fill);
  // Do other stuff
  malloc(100);
}


int zero_fill(int nAllocType, 
              void* pvData, 
              size_t nSize,
              int nBlockUse, 
              long lRequest, 
              const unsigned char *szFileName, 
              int nLine )
{
  /// Very Importaint !! 
  /// infinite recursion if this is removed !!
  /// _CRT_BLOCK must not do any thing but return TRUE
  /// even calling printf in the _CRT_BLOCK will cause
  /// infinite recursion
  if ( nBlockUse == _CRT_BLOCK )
    return( TRUE );
  switch(nAllocType)
  {
  case _HOOK_ALLOC:
  case _HOOK_REALLOC:
    // zero initialize the allocated space.
    memset(pvData,0,nSize);
    break;
  case _HOOK_FREE:
    break;
  }
  return TRUE;
}

если вы используете malloc, он ни к чему не инициализирует память. вы получите что угодно. если вы хотите выделить блок и инициализировать его значением 0, используйте calloc, который похож на malloc только с инициализацией (параметр размера элемента, который вы устанавливаете на 1, если хотите эмулировать malloc). вы должны прочитать о calloc перед его использованием, так как он имеет некоторые незначительные отличия.

http://wiki.answers.com/Q/What_is_the_difference_between_malloc_and_calloc_functions

На самом деле это очень хорошая функция в VC++ (и я верю в другие компиляторы), потому что она позволяет вам видеть нераспределенную память для указателя в отладчике. Я дважды подумаю, прежде чем отключать эту функцию. Когда вы удаляете объект в C++, вы должны установить указатель на NULL на случай, если что-то позже попытается удалить объект снова. Эта функция позволит вам обнаружить места, где вы забыли установить указатель на NULL.

Почему бы не создать свой собственный #define и не выработать привычку его использовать?

Т.е.

#define SafeDelete(mem) { delete mem; mem = NULL; }
#define SafeDeleteArray(mem) { delete [] mem; mem = NULL; }

Очевидно, вы можете называть это как угодно. deleteZ, deletesafe, все, что вам удобно.

Ты говоришь:

I create and initialize a variable (via new), and that all goes just fine. When I free it (via delete), it sets the pointer to 0xFEEEFEEE instead of NULL. When I insert a proper check for NULL, as all good programs that manage their own memory should, I come up with problems as 0xFEEEFEEE passes a NULL check without problems.

Даже процедуры кучи отладки MSVC не изменят значение удаляемого указатель - значение удаляемого указателя не изменится (даже на NULL). Похоже, вы обращаетесь к указателю, который принадлежит только что удаленному объекту, что является простой и простой ошибкой.

Я почти уверен, что то, что вы пытаетесь сделать, просто скроет недействительный доступ к памяти. Вы должны опубликовать фрагмент кода, чтобы показать нам, что на самом деле происходит.

@ Джефф Хаббард (комментарий):

This actually inadvertently provides me with the solution I want: I can set pvData to NULL on _HOOK_FREE and not run into problems with 0xFEEEFEEE for my pointer address.

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

Это ошибка.

«Решение», которое вы используете, просто скрывает, а не исправляет ошибку. Когда эта освобожденная память когда-либо будет выделена для чего-то другого, вы внезапно будете использовать неправильное значение в качестве указателя на неправильную вещь.

@ [Джефф Хаббард]:

What's happening is my code crashes under a debug compilation, but succeeds under a release compilation. I've checked it under a debugger and my pointers are getting set to 0xFEEEFEEE after I call delete on them. Again, same code on release doesn't crash and behaves as expected.

Это очень странное поведение - я все еще убежден, что, вероятно, существует скрытая ошибка, которую скрывает обходной путь _CrtSetAllocHook().

Подпись 0xFEEEFEEE используется диспетчером кучи ОС для обозначения освобожденной памяти (см. http://www.nobugs.org/developer/win32/debug_crt_heap.html). Не могли бы вы опубликовать репро-код и указать, какую именно версию компилятора вы используете?

Если он работает в режиме выпуска, то это из-за удачи.

Майк Б. прав, предполагая, что исправление отладки скрывает ошибку. В режиме выпуска используется указатель, который был освобожден, но не установлен на NULL, а память, на которую он указывает, все еще «действительна». В какой-то момент в будущем изменится распределение памяти, или изображение памяти изменится, или что-то заставит «действительный» блок памяти стать «недействительным». В этот момент ваша сборка выпуска начнет давать сбой. Переход в режим отладки для поиска проблемы будет бесполезным, потому что режим отладки был «исправлен».

Я думаю, мы все согласны с тем, что следующий код не должен работать.

char * p = new char[16];     // 16 bytes of random trash
strcpy(p, "StackOverflow");  // 13 characters, a '\0' terminator, and two bytes of trash
delete [] p;                 // return 16 bytes to the heap, but nothing else changes;

if (p != NULL)               // Why would p be NULL?  It was never set to NULL
    ASSERT(p[0] == 'S');     // In debug, this will crash, because p = 0xfeeefeee and 
                             // dereferencing it will cause an error.
                             // Release mode may or may or may not work, depending on
                             // other memory operations

Как сказано почти в каждом другом плакате, указатели должны быть установлены на NULL после вызова delete. Независимо от того, делаете ли вы это сами, или используете boost, или другую оболочку, или даже макрос в этом потоке, зависит от вас.

What's happening is my code crashes under a debug compilation, but succeeds under a release compilation.

Сборка релиза выйдет из строя на машине клиента. Так всегда бывает.

I've checked it under a debugger and my pointers are getting set to 0xFEEEFEEE after I call delete on them.

Указатели не изменяются после того, как вы вызываете для них удаление. Это память, на которую они указывают, устанавливается в 0xfeeefeee, 0xfeeefeee, ..., 0xfeeefeee.

Если вы заметили, что ваша программа считывает данные из освобожденной памяти (что удобно обозначено шаблоном 0xfeeefeee в сборке DEBUG), у вас есть ошибка.

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