When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?

Question

I know that the OS will sometimes initialise memory with certain patterns such as 0xCD and 0xDD. What I want to know is when and why this happens.

When

Is this specific to the compiler used?

Do malloc/new and free/delete work in the same way with regard to this?

Is it platform specific?

Will it occur on other operating systems, such as Linux or VxWorks?

Why

My understanding is this only occurs in Win32 debug configuration, and it is used to detect memory overruns and to help the compiler catch exceptions.

Can you give any practical examples as to how this initialisation is useful?

I remember reading something (maybe in Code Complete 2) that it is good to initialise memory to a known pattern when allocating it, and certain patterns will trigger interrupts in Win32 which will result in exceptions showing in the debugger.

How portable is this?

Answer 1

It's compiler and OS specific, Visual studio sets different kinds of memory to different values so that in the debugger you can easily see if you have overun into into malloced memory, a fixed array or an uninitialised object. Somebody will post the details while I am googling them...

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

Answer 2

The obvious reason for the "why" is that suppose you have a class like this:

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

private:
    SomeObject *_obj;
}

And then you instantiate one a Foo and call SomeFunction, it will give an access violation trying to read 0xCDCDCDCD. This means that you forgot to initialize something. That's the why part. If not, then the pointer might have lined up with some other memory, and it would be more difficult to debug. It's just letting you know the reason that you get an access violation. Note that this case was pretty simple, but in a bigger class it's easy to make that mistake.

AFAIK, this only works on the visual studio compiler when in debug mode (as opposed to release)

Answer 3

It's not the OS - it's the compiler. You can modify the behaviour too - see down the bottom of this post.

Microsoft Visual Studio generates (in Debug mode) a binary that pre-fills stack memory with 0xCC. It also inserts a space between every stack frame in order to detect buffer overflows. A (very simple - in practice Visual Studio would spot this problem and issue a warning) example of where this is useful is here:

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

If Visual Studio didn't preinitialise variables to a known value, then this bug could potentially be hard to find. With preinitialised variables (or rather, preinitialised stack memory), the problem is reproducible on every run.

However, there is a slight problem. The value Visual Studio uses is TRUE - anything except 0 would be. It is actually quite likely that when you run your code in Release mode that unitialised variables may be allocated to a piece of stack memory that happens to contain 0, which means you can have an unitialised variable bug which only manifests itself in Release mode.

That annoyed me, so I wrote a script to modify the pre-fill value by directly editing the binary, allowing me to find uninitalized variable problems that only show up when the stack contains a zero. This script only modifies the stack pre-fill; I never experimented with the heap pre-fill, though it should be possible. Might involve editing the run-time DLL, might not...

Answer 4

It's to easily see that memory has changed from its initial starting value, generally during debugging but sometimes for release code as well, since you can attach debuggers to the process while it's running.

It's not just memory either, many debuggers will set register contents to a sentinel value when the process starts (AIX sets its registers to 0xdeadbeef which is mildly humorous).

Answer 5

Once nice property about the fill value 0xCCCCCCCC is that in x86 assembly, the opcode 0xCC is the int3 opcode, which is the software breakpoint interrupt. So, if you ever try to execute code in uninitialized memory that's been filled with that fill value, you'll immediately hit a breakpoint, and the operating system will let you attach a debugger (or kill the process).

Answer 6

A quick summary of what Microsoft's compilers use for various bits of unowned/uninitialized memory when compiled for debug mode (support may vary by compiler version):

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. 

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.

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().

Disclaimer: the table is from some notes I have lying around - they may not be 100% correct (or coherent).

As others have noted, one of the key properties of these values is that is a pointer variable with one of these values is dereferenced, it will result in an access violation, since on a standard 32-bit Windows configuration, user mode addresses will not go higher than 0x7fffffff.

Answer 7

The IBM XLC compiler has an "initauto" option that will assign automatic variables a value that you specify. I used the following for my debug builds:

-Wc,'initauto(deadbeef,word)'

If I looked at the storage of an uninitialized variable, it would be set to 0xdeadbeef

Answer 8

This article describes unusual memory bit patterns and various techniques you can use if you encounter these values.

Answer 9

As others have mentioned, this is Windows-specific; the fill patterns are used by the Win32 Debug Heap.

There is a handy table describing the state of the debug heap and the flag bytes it uses on Andrew Birkett's Win32 Debug CRT Heap Internals page.

I keep a copy hung on my wall for really quick reference; I can never keep the flags straight :-)

Answer 10

Does anyone know what gcc does?