Archived

This topic is now archived and is closed to further replies.

nosajghoul

_BLOCK_TYPE_IS_VALID

Recommended Posts

what does that mean? Basically, an error window pops up saying --------------------------------- debug assertion failed! . . . Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) . . . --------------------------------- What does this mean, how do I fix it? See my previous post today for how I came to this. (short version : deleting a pointer) -Jason

Share this post


Link to post
Share on other sites
Nope, Im 99.9% sure thats not the case here. I trace it up to the delete comment, the thing to be deleted (cVideo *video)still has an address (not 0x00000000 or anything like that) Then I F-10 over it and thats when that window pops up.

Now there are objects (DirectShow objects) that still have valid addresses ^inside^ this object (cVideo *video). Ive called the appropriate ->Release() function for them all tho... When I try to delete THOSE objects (before OR after the ->Release() calls) it gives me the same error.

I havent given up yet, and am looking into "how your program can cause assertion failure". Still, way stumped here.

-Jason



Share this post


Link to post
Share on other sites
Just because it has a valid address, doesn''t mean it hasn''t been deleted. Deleting the memory a pointer points to doesn''t change the value of the pointer itself.


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
It could also mean you've somehow written beyond the block of memory allocated for use by the pointer.

edit: So, run the debugger and find the line it crashes on, and trace back through code that uses the pointer

[edited by - zealouselixir on October 23, 2003 9:32:53 PM]

Share this post


Link to post
Share on other sites
seeing this almost always means you''ve overwritten some important memory somewhere. Unfortunately, it''s going to be difficult to figure out exactly where, because this usually is invoked when delete tries to free up memory, and its internal data structures are corrupted(because you overwrote them). So, try to ensure that you don''t access an array out-of-bounds, and that your pointers are valid.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This has happened to me as well while running a game I developed in DirectX. It happened when the screensaver kicked on. So i intercepted the screensaver and power management messages, and prevented them from being processed. Solved my problem.

Added the following to WndProc in the switch statement processing the message.

case WM_SYSCOMMAND:
{
switch(wParam)
{
case SC_SCREENSAVE:
case SC_MONITORPOWER:
return 0;
}
break;
}

Share this post


Link to post
Share on other sites
Does memory address 0xdddddddd bear any significance? All the objects I release end up pointing there.

More specifically : setting the inner objects (the DirectShow objects) to NULL after releasing them, and then deleting their container object (the global cVideo *video) always sets the inner objects address to 0xdddddddd, which makes me wonder the significance of that address.

Boy its a learning night tonight!

-Jason

Share this post


Link to post
Share on other sites
Could it have something to do with DLLs and the debug module using different heaps??? Would kinda make sense since dshow is all a DLL and not a .h like the rest of DirectX.

here : http://www.libsdl.org/pipermail/sdl/1999-April/020636.html talks about that.

here : http://lists.wxwindows.org/archive/wx-users/msg24813.html tells how to be able to delete across "modules". I dont think thats the way to do it though, and Im starting tho think (gasp!) of just letting the memory leak.

-Jason


Share this post


Link to post
Share on other sites