4

----------------EDIT-----------------------

I was grabbing the wrong value for comparison, the cdcdcdcd was coming from somewhere else. I still have my methods throwing exceptions before they are even reached, but my problem lies elsewhere, I wish there was a way to just "unpost" my original question. Thanks for the help.

----------------EDIT-----------------------

I have a class (MyClass) I have inherited from some third party class (which in turn derives from direct show classes - from CBaseFilter if this matters). I write this code:

MyClass* val = NULL;
val = new MyClass(); // Create an instance of the class.

Attempting to make method calls results in a thrown exception. With a little sleuthing I found that when I dereference val (val itself seems valid... something like 0x0777fc90), it contains 0xcdcdcdcd. I looked around and it seems that this might indicate that the memory has been allocated on the heap, but not initialized.

What does that mean?! How can the call to new succeed (val != NULL) and yet the memory isn't initialized enough to have a pointer to it? Is it possible that something went wrong with some of the base class initialization? And if so - what am I looking for?

Steven
  • 181
  • 1
  • 2
  • 11
  • 4
    Looking at the constructor of `MyClass` would be a start. – Kerrek SB Nov 26 '11 at 00:33
  • 1
    The code you posted is fine, probably the problem lies somewhere else in your code, e.g. in your constructor. – Matteo Italia Nov 26 '11 at 00:34
  • I don't understand what I'm looking for - the constructor doesn't throw any exceptions. It initializes a bunch of static members to 0. – Steven Nov 26 '11 at 00:37
  • 1
    @Steven: They're asking you to post your constructor and its members. Also, `static` members shouldn't be initialized in an objects constructor, only non-static members. And at exactly what function call does this initialization happen? In short: post your class. – Nicol Bolas Nov 26 '11 at 00:43
  • My code is too trivial - I'm guessing the problem is in the base classes somewhere, but don't know where to look. You're right about the static members, I misspoke and meant that it set member values to 0. This is my constructor: MyClass::MyClass() : CParserFilter(TEXT("Some Name", NULL, 0) { mInitialized = false; } – Steven Nov 26 '11 at 00:51

1 Answers1

16

0xCDCDCDCD is a debugging value that comes from the bowels of the C runtime library. When you allocate a block of memory in a debug build, it's initialized to this spurious value in the hope of catching bugs. 0xCDCDCDCD is non-NULL and is never a valid memory pointer.

Is there an HRESULT that passes up through from DirectShow that you can check?

Try calling WINAPI function GetLastError() and see what that shows.

AJM
  • 1,317
  • 2
  • 15
  • 30
bobobobo
  • 64,917
  • 62
  • 258
  • 363
  • Called GetLastError both before and after constructor - no change (it's 2 for some reason... but shouldn't matter, probably came from something else). HRESULT from the constructor comes back as S_OK. – Steven Nov 26 '11 at 00:50
  • Also you can use the error lookup tool from DirectX sdk. – AlexTheo Nov 26 '11 at 01:17
  • You really should double check what `GetLastError()` may be telling you - [use this](http://bobobobo.wordpress.com/2009/02/02/getlasterror-and-getlasterrorasstring/). Without additional information, I don't think anyone can help you further. – bobobobo Nov 26 '11 at 02:32
  • Thank you for your help - the problem was in Visual Studio's automatic use of a macro when creating certain classes (ATL_NO_VTABLE). Removing that macro fixed my problem. – Steven Nov 26 '11 at 03:01
  • 5
    CD is also the opcode for an x86 interrupt instruction. CD CD would trigger interrupt number CD. If your code somehow tries to execute this block of memory, the OS can quickly catch it and put it out of its misery. – Ferruccio Nov 26 '11 at 13:18
  • https://en.wikipedia.org/wiki/Magic_number_(programming)#cite_ref-Win32CRTDebugHeapInternals_23-2:~:text=CDCDCDCD,HeapAlloc()%5B24%5D is the exact place where you can see this magic number. – joepol Sep 21 '22 at 08:48