What can cause VTable pointer to be 0xdddddddd in Win32 debug build?

Question

I am debugging a defect and have narrowed it down to the vtable pointer for an object being 0xdddddddd. This answer indicates that Win32 debug builds will generally set dead memory, or memory which has been deleted, to this special value.

Note that the pointer itself looks valid, it's just the vtable pointer that is 0xdddddddd.

Here's a snippet of code:

std::list<IMyObject*>::const_iterator it;
for (it = myObjects.begin(); it != myObjects.end(); ++it)
{
    IMyObject* pMyObject = *it;
    if (pMyObject == 0)
        continue;

    pMyObject->someMethod(); // Access violation     
}

If I break at the line of the access violation and watch pMyObject, I can see that pMyObject itself has a valid address (0x08ede388) but the __vfptr member is invalid (0xdddddddd).

Some notes:

• It's a single-threaded application, so this is most likely not a race condition or mutex issue.
• There don't appear to be any obvious issues like deleting the object further up the call stack before accessing it.
• This issue seems to only be reproducible on Windows 2008 server, but not on Windows 7.

Any suggestions about how to debug this further?

Answer 1

You are using the pointer after it has been released. Get a stack trace from a breakpoint in the destructor to see what is deleting it. Or better yet, use shared_ptr<> to avoid the problem.