<p>As everyone knows, the <a href="http://en.wikipedia.org/wiki/Visual_C%2B%2B" rel="nofollow noreferrer">Visual C++</a> runtime marks uninitialized or just freed memory blocks with special non-zero markers. Is there any way to disable this behavior entirely without manually setting all uninitialized memory to zeros? It's causing havoc with my valid not null checks, since <code>0xFEEEFEEE != 0</code>.</p>

<p>Hrm, perhaps I should explain a bit better. 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 <code>0xFEEEFEEE</code> instead of <code>NULL</code>. When I insert a proper check for <code>NULL</code>, as all good programs that manage their own memory should, I come up with problems as <code>0xFEEEFEEE</code> passes a <code>NULL</code> check without problems. Is there any good way, other than manually setting all pointers to <code>NULL</code> when deleting them, to detect when memory has already been freed? I would prefer to not use <a href="http://en.wikipedia.org/wiki/Boost_C%2B%2B_Libraries" rel="nofollow noreferrer">Boost</a> simply because I don't want the overhead, small though it may be, since that's the only thing I'd be using Boost for.</p>

[{'answer_id': 65760, 'author': 'Eclipse', 'author_id': 8701, 'author_profile': 'https://Stackoverflow.com/users/8701', 'pm_score': 4, 'selected': False, 'text': '<p>When you create a pointer, explicity initialize it to <code>NULL</code>. Likewise after a <code>delete</code>. Depending on the value of uninitialized data (except in a few specific cases) is asking for trouble.</p>\n\n<p>You can save yourself a lot of headaches by using a smart pointer class (such as <a href="http://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/shared_ptr.htm" rel="nofollow noreferrer"><code>boost::shared_ptr</code></a>) which will automatically deal with whether a pointer is initialized or not.</p>\n'}, {'answer_id': 65777, 'author': 'Fire Lancer', 'author_id': 6266, 'author_profile': 'https://Stackoverflow.com/users/6266', 'pm_score': 0, 'selected': False, 'text': "<p>I'm pretty sure you can't disable the visual studio default here, and even if you did, the value would then be just whatever was in memory before the memory was allocated.</p>\n\n<p>Your best off just getting in the habit of setting them to 0 in the first place, it's only 2 extra charecters.</p>\n\n<pre><code>int *ptr=0;\n</code></pre>\n\n<p>You can also use the NULL macro, which is defined as 0 (but not be default, so be carful with multiple definitions when includeing stuff like windows.h and defining it yourself!</p>\n"}, {'answer_id': 65789, 'author': 'Rob Walker', 'author_id': 3631, 'author_profile': 'https://Stackoverflow.com/users/3631', 'pm_score': 4, 'selected': False, 'text': "<p>VC++'s behaviour shouldn't cause havoc with any <strong>valid</strong> check you can do.  If you are seeing the 0xfeeefeee then you haven't written to the memory (or have freed it), so you shouldn't be reading from the memory anyway.</p>\n"}, {'answer_id': 65792, 'author': 'Adam Rosenfield', 'author_id': 9530, 'author_profile': 'https://Stackoverflow.com/users/9530', 'pm_score': 3, 'selected': False, 'text': '<p>If you build in Release mode instead of Debug mode, the runtime does not fill uninitialized memory at all, but it will still not be zeros.  However, you should <b>not</b> depend on this behavior - you should either explicitly initialize the memory yourself with memset(), ZeroMemory(), or SecureZeroMemory(), or set a flag somewhere indicating that the memory is not yet initialized.  Reading uninitialized memory will result in undefined behavior.</p>\n'}, {'answer_id': 65799, 'author': 'Andy Ross', 'author_id': 9555, 'author_profile': 'https://Stackoverflow.com/users/9555', 'pm_score': 3, 'selected': False, 'text': '<p>If you\'re reading uninitialized memory, your checks are most certainly not "valid".  The memory is freed.  It might already be in use for something else.  You can\'t make any assumptions about the contents of uninitialized memory in C/C++.</p>\n\n<p>Java (and C#, I believe) will guaranteed that allocated memory is zeroed before use, and of course the garbage collection prevents you from seeing freed memory at all.  But that isn\'t a property of the C heap, which exposes the memory directly.</p>\n'}, {'answer_id': 66036, 'author': 'Ted', 'author_id': 8965, 'author_profile': 'https://Stackoverflow.com/users/8965', 'pm_score': 4, 'selected': True, 'text': "<p>It is not the responsibility of <code>delete</code> to reset all the pointers to the object to <code>NULL</code>.\nAlso you shouldn't change the default memory fill for the windows DEBUG runtime and you should use some thing like <code>boost::shared_ptr&lt;&gt;</code> for pointers any way.</p>\n\n<p>That said, if you really want to <strong>shoot your self in the foot</strong> you can.</p>\n\n<p>You can <strong>change</strong> the <strong>default fill</strong> for the windows <strong>DEBUG runtime</strong> by using an allocator hook like this. This will only work on HEAP allocated object!</p>\n\n<pre><code>int main(int argc,char** arv)\n{\n  // Call first to register hook    \n  _CrtSetAllocHook(&amp;zero_fill);\n  // Do other stuff\n  malloc(100);\n}\n\n\nint zero_fill(int nAllocType, \n              void* pvData, \n              size_t nSize,\n              int nBlockUse, \n              long lRequest, \n              const unsigned char *szFileName, \n              int nLine )\n{\n  /// Very Importaint !! \n  /// infinite recursion if this is removed !!\n  /// _CRT_BLOCK must not do any thing but return TRUE\n  /// even calling printf in the _CRT_BLOCK will cause\n  /// infinite recursion\n  if ( nBlockUse == _CRT_BLOCK )\n    return( TRUE );\n  switch(nAllocType)\n  {\n  case _HOOK_ALLOC:\n  case _HOOK_REALLOC:\n    // zero initialize the allocated space.\n    memset(pvData,0,nSize);\n    break;\n  case _HOOK_FREE:\n    break;\n  }\n  return TRUE;\n}\n</code></pre>\n"}, {'answer_id': 67751, 'author': 'user10370', 'author_id': 10370, 'author_profile': 'https://Stackoverflow.com/users/10370', 'pm_score': 0, 'selected': False, 'text': '<p>if you are using malloc, it does not intialize the memory to anything. you get whatever. if you want to allocate a block and initialize it to 0, use \'calloc\' which is like malloc only with initialization (an an element size parameter which you set to 1 if you want to emulate malloc). you should read up on calloc before using it as it has some slight differences.</p>\n\n<p><a href="http://wiki.answers.com/Q/What_is_the_difference_between_malloc_and_calloc_functions" rel="nofollow noreferrer">http://wiki.answers.com/Q/What_is_the_difference_between_malloc_and_calloc_functions</a></p>\n'}, {'answer_id': 69116, 'author': 'Curro', 'author_id': 10688, 'author_profile': 'https://Stackoverflow.com/users/10688', 'pm_score': 2, 'selected': False, 'text': '<p>That is actually a very nice feature in VC++ (and I believe other compilers) because it allows you to see unallocated memory for a pointer in the debugger. I will think twice before disabling that functionality. When you delete an object in C++ you should set the pointer to <code>NULL</code> in case something later tries to delete the object again. This feature will allow you to spot the places where you forgot to set the pointer to <code>NULL</code>.</p>\n'}, {'answer_id': 69199, 'author': 'Cliff Cawley', 'author_id': 10957, 'author_profile': 'https://Stackoverflow.com/users/10957', 'pm_score': 0, 'selected': False, 'text': "<p>Why not create your own #define and get in the habit of using it?</p>\n\n<p>I.e.</p>\n\n<pre><code>#define SafeDelete(mem) { delete mem; mem = NULL; }\n#define SafeDeleteArray(mem) { delete [] mem; mem = NULL; }</code></pre>\n\n<p>Obviously you can name it whatever you like. deleteZ, deletesafe, whatever you're comfortable with.</p>\n"}, {'answer_id': 73835, 'author': 'Michael Burr', 'author_id': 12711, 'author_profile': 'https://Stackoverflow.com/users/12711', 'pm_score': 3, 'selected': False, 'text': "<p>You say: </p>\n\n<blockquote>\n  <p>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.</p>\n</blockquote>\n\n<p>Even the debug heap routines of MSVC will not change the value of the <strong>pointer</strong> you're deleting - the value of the pointer you're deleting will not change (even to NULL).  It sounds like you're accessing a pointer that belongs to the object you've just deleted, which is a bug, plain and simple.</p>\n\n<p>I'm pretty sure that what you're trying to do will simply cover up an invalid memory access. You should post a snippet of code to show us what is really happening.</p>\n"}, {'answer_id': 77758, 'author': 'Michael Burr', 'author_id': 12711, 'author_profile': 'https://Stackoverflow.com/users/12711', 'pm_score': 2, 'selected': False, 'text': '<p>@Jeff Hubbard (<a href="https://stackoverflow.com/questions/65724/uninitialized-memory-blocks-in-vc/66036#66036">comment</a>):</p>\n\n<blockquote>\n  <p>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.</p>\n</blockquote>\n\n<p>If this is working for you, then it means that you are reading freed memory when you\'re testing for the NULL pointer (ie., the pointer itself resides in the memory you freed).</p>\n\n<p>This is a bug.</p>\n\n<p>The \'solution\' you\'re using is simply hiding, not fixing, the bug.  When that freed memory ever gets allocated to something else, suddenly you\'ll be using the wrong value as a pointer to the wrong thing.</p>\n'}, {'answer_id': 79170, 'author': 'Michael Burr', 'author_id': 12711, 'author_profile': 'https://Stackoverflow.com/users/12711', 'pm_score': 1, 'selected': False, 'text': '<p>@[Jeff Hubbard]:</p>\n\n<blockquote>\n  <p>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 <code>0xFEEEFEEE</code> after I call delete on them. Again, same code on release doesn\'t crash and behaves as expected.</p>\n</blockquote>\n\n<p>This is very strange behavior - I\'m still convinced that there\'s probably a latent bug that\'s being hidden by the <code>_CrtSetAllocHook()</code> workaround.</p>\n\n<p>The <code>0xFEEEFEEE</code> signature is used by the OS heap manager to indicate freed memory (see <a href="http://www.nobugs.org/developer/win32/debug_crt_heap.html" rel="nofollow noreferrer">http://www.nobugs.org/developer/win32/debug_crt_heap.html</a>). By any chance can you post some repro code and indicate exactly which compiler version you\'re using?</p>\n'}, {'answer_id': 79587, 'author': 'Dan Shield', 'author_id': 4633, 'author_profile': 'https://Stackoverflow.com/users/4633', 'pm_score': 2, 'selected': False, 'text': '<p>If it\'s working in release mode, it\'s because of shear luck.  </p>\n\n<p>Mike B is right to assume that the debug fix is hiding a bug.  In release mode, a pointer is being used that has been freed but not set to <code>NULL</code>, and the memory it points to is still "valid".  At some point in the future, memory allocations will change, or the memory image will change, or something will cause the "valid" memory block to become "invalid".  At that point, your release build will start failing.  Switching to debug mode to find the problem will be useless, because the debug mode has been "fixed".</p>\n\n<p>I think we call all agree that the following code shouldn\'t work.</p>\n\n<pre><code>char * p = new char[16];     // 16 bytes of random trash\nstrcpy(p, "StackOverflow");  // 13 characters, a \'\\0\' terminator, and two bytes of trash\ndelete [] p;                 // return 16 bytes to the heap, but nothing else changes;\n\nif (p != NULL)               // Why would p be NULL?  It was never set to NULL\n    ASSERT(p[0] == \'S\');     // In debug, this will crash, because p = 0xfeeefeee and \n                             // dereferencing it will cause an error.\n                             // Release mode may or may or may not work, depending on\n                             // other memory operations\n</code></pre>\n\n<p>As just about every other poster has said, pointers should be set to <code>NULL</code> after calling <code>delete</code>. Whether you do it yourself or use boost or some other wrapper or even the macro in this thread is up to you.  </p>\n'}, {'answer_id': 346462, 'author': 'Constantin', 'author_id': 20310, 'author_profile': 'https://Stackoverflow.com/users/20310', 'pm_score': 2, 'selected': False, 'text': "<blockquote>\n  <p>What's happening is my code crashes\n  under a debug compilation, but\n  succeeds under a release compilation.</p>\n</blockquote>\n\n<p>Release build will crash on customer's machine. It always does.</p>\n\n<blockquote>\n  <p>I've checked it under a debugger and\n  my pointers are getting set to\n  0xFEEEFEEE after I call delete on\n  them.</p>\n</blockquote>\n\n<p><em>Pointers</em> are not changed after you call delete on them. It's the memory they point to that gets set to 0xfeeefeee, 0xfeeefeee, ..., 0xfeeefeee.</p>\n\n<p>If you spot that your program reads data from freed memory (which is conveniently indicated by 0xfeeefeee pattern in DEBUG build), you have a bug.</p>\n"}, {'answer_id': 26003711, 'author': 'Scott Jasin', 'author_id': 2679456, 'author_profile': 'https://Stackoverflow.com/users/2679456', 'pm_score': 0, 'selected': False, 'text': '<p>You could create a memory manager also. Then you could override new and delete to pull from/put back a pre allocated chuck of memory.</p>\n'}]
['https://Stackoverflow.com/questions/65724', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/8844/']