How to end up with a pointer to 0xCCCCCCCC

Question

Hi,

The program I'm working on crashes sometimes trying to read data at the address 0xCCCCCCCC. Google (and StackOverflow) being my friends I saw that it's the MSVC debug code for uninitialized stack variable. To understand where the problem can come from, I tried to reproduce this behavior: problem is I haven't been able to do it.

Question is: have you a code snippet showing how a pointer can end pointing to 0xCCCCCCCC?

Thanks.

Answer 1

int main()
{
    int* p;
}

If you build with the Visual C++ debug runtime, put a breakpoint in main(), and run, you will see that p has a value of 0xcccccccc.

Answer 2

I do not have MSVC, but this code should produce the problem and compile with no warnings.

In file f1.c:

void ignore(int **p) { }

In file f2.c:

void ignore(int **p);
int main(int c, char **v)
{
  int *a;
  ignore(&a);
  return *a;
}

The call to ignore makes it look like a might be initialized. I doubt the compiler will warn in this case, because of the risk that the warning might be a false positive.

Answer 3

I'm not sure, but you may look at memory leaks and whether an instance of the below code pattern appears anywhere. Its role is to turn bits in a variable backwards.This is one common place I know where literal 0xCCCCCCCC appears.

 x = (x & 0xFFFF0000) << 16 | (x & 0x0000FFFF) >> 16;
 x = (x & 0xFF00FF00) <<  8 | (x & 0x0000FFFF) >> 8;
 x = (x & 0xF0F0F0FF) <<  4 | (x & 0x0F0F0F0F) >> 4;
 x = (x & 0xCCCCCCCC) <<  2 | (x & 0x33333333) >> 2;
 x = (x & 0xaaaaaaaa) <<  1 | (x & 0x55555555) >> 1;

Answer 4

Compile your code with the /GZ compiler switch or /RTCs switch. Make sure that /Od switch is also used to disable any optimizations.

s

Enables stack frame run-time error checking, as follows:

• Initialization of local variables to a nonzero value. This helps identify bugs that do not appear when running in debug mode. There is a greater chance that stack variables will still be zero in a debug build compared to a release build because of compiler optimizations of stack variables in a release build. Once a program has used an area of its stack, it is never reset to 0 by the compiler. Therefore, subsequent, uninitialized stack variables that happen to use the same stack area can return values left over from the prior use of this stack memory.

• Detection of overruns and underruns of local variables such as arrays. /RTCs will not detect overruns when accessing memory that results from compiler padding within a structure. Padding could occur by using align (C++), /Zp (Struct Member Alignment), or pack, or if you order structure elements in such a way as to require the compiler to add padding.

• Stack pointer verification, which detects stack pointer corruption. Stack pointer corruption can be caused by a calling convention mismatch. For example, using a function pointer, you call a function in a DLL that is exported as __stdcall but you declare the pointer to the function as __cdecl.

Answer 5

How about this? Ignore the warning that VC throws while running.

struct A{
    int *p;
};

int main(){
    A a;
    cout << (void *)a.p;
}