With C++, I Get Pointer with 0Xcdcdcdcd When Creating a Class - What Is Happening

CDCDCDCD pointer. Creating stack of stacks

You never initialize any of your pointers, and the behavior when attempting to dereference an uninitialized pointer (or read from any uninitialized variable) is undefined. Many compilers will fill uninitialized memory with some distinctive pattern (like 0xCDCDCDCD) when you compile in debug mode to make these sorts of errors more apparent.

You need to add constructors to your structs that initialize their members to some initial value or ensure their members are initialized in some other way.

What happen with the pointer members of a class if I declare a pointer?

It is a wild pointer. VC compilers assign to those pointers the value 0xcdcdcdcd which may point to the last memory in the RAM ( not sure of that) . You should not dereference this kind of pointers because the compiler will throw a violation memory access.If you doesn't want to assign a object of type Node to the pointer it is strongly recommended that you assign the pointer with NULL value.In this case you will always be able to check in the code if the pointer points to a real object or is not assigned by checking his address.

C++ Access violation reading location 0xcdcdcdcd error on calling a function

ptr is a pointer to a myClass, but you don't seem to ever initialize it. In other words, ptr isn't pointing to anything. It's uninitialized -- pointing in to hyperspace.

When you try to use this uninitialized pointer,

ptr->bubSort(...);

You get Undefined Behavior. You're actually lucky that the application crashed, because anything else could have happened. It could have appeared to work.

To fix this problem directly, you need to initialize ptr. One way:

class sampleClass
{
public:
  sampleClass()
  :
    ptr (new myClass)
  {
  }
};

(For an explanation about the funky : syntax, look up "initialization list")

But this uses dynamic allocation, which is best avoided. One of the main reasons why dynamic allocation is best avoided is because you have to remember to delete anything you new, or you will leak memory:

class sampleClass
{
public:
  ~sampleClass()
  {
    delete ptr;
  }
};

Ask yourself if you really need a pointer here, or would doing without be ok?

class sampleClass
{
public:
  myClass mMyClass;
};

sampleClass::func(...)
{
  mMyClass.func();
}

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

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

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

Many of these values are defined in 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 */

There are also a few times where the debug runtime will fill buffers (or parts of buffers) with a known value, for example, the 'slack' space in std::string's allocation or the buffer passed to fread(). Those cases use a value given the name _SECURECRT_FILL_BUFFER_PATTERN (defined in crtdefs.h). I'm not sure exactly when it was introduced, but it was in the debug runtime by at least VS 2005 (VC++8).

Initially, the value used to fill these buffers was 0xFD - the same value used for no man's land. However, in VS 2008 (VC++9) the value was changed to 0xFE. I assume that's because there could be situations where the fill operation would run past the end of the buffer, for example, if the caller passed in a buffer size that was too large to fread(). In that case, the value 0xFD might not trigger detecting this overrun since if the buffer size were too large by just one, the fill value would be the same as the no man's land value used to initialize that canary. No change in no man's land means the overrun wouldn't be noticed.

So the fill value was changed in VS 2008 so that such a case would change the no man's land canary, resulting in the detection of the problem by the runtime.

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

---

Related Topics