Assertion Failure

Started by
8 comments, last by iMalc 13 years, 6 months ago

When I close the program I get:

Debug Assertion Failed!

Program: ...\TheGame.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

and then i get the choices Abort || Retry || Ignore

all I really can do is Abort.





++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I don't know what this is. I am getting this and i am trying to figure it out on my own but its not going very well.


Other than assertion failure, do I have to make sure all my pointers point to \0 when I am done with them?

[Edited by - EvanBlack on September 25, 2010 5:56:11 PM]
Visual Studio 2008Visual C++SFML
Advertisement
Post exactly the error message or popup message that you are getting.

Then if you can use the debugger to step through your code (put a breakpoint on the first line and then go slowly step by step). You should hit one step that causes the assertion to fire. Post that code below and what line is the problem and we can help tell you what is wrong.

You are probably trying to do something to a pointer that is uninitialized or deleted, but other than that we need more information.
[size=2]My Projects:
[size=2]Portfolio Map for Android - Free Visual Portfolio Tracker
[size=2]Electron Flux for Android - Free Puzzle/Logic Game
When I close the program I get:

Debug Assertion Failed!

Program: ...\TheGame.exe
File: f:\dd\vctools\crt_bld\self_x86\crt\src\dbgdel.cpp
Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

and then i get the choices Abort || Retry || Ignore

all I really can do is Abort.
Visual Studio 2008Visual C++SFML
I think what Karwosts was suggesting is a better course of action that repeating what you have already said. The definition of insanity is repeating an action and expecting a different result. Next time, break into the debugger and check the callstack, which should point you to the function causing the issues. Post the code up and someone will be able to help you and your sanity...
Quote:
Other than assertion failure, do I have to make sure all my pointers point to \0 when I am done with them?

You should certainly use "delete" with any pointers that point to dynamically allocated memory you aren't using any more.

Nulling pointers when you're done with them is pointless - as you won't be using them again. Ideally, you'd never touch them again: so whether they're null or not doesn't matter. In practise, bugs might result in accessing pointers that should never be used again, so setting them to a special invalid value can be a good idea.

Invalid pointers won't cause assertion errors (in general), they cause segmentation faults or subtle memory corruption that manifests later on as some bizarre behaviour or data.
With assertion failures in debug mode, I believe "retry" attaches the debugger.
I fixed it but I don't know why this is wrong. Maybe I need to learn more about these constructors and destructors.

The problem:

[source c++]GameObject::~GameObject(){	delete this->dpSquare;	delete this->atSquare;}



The solution:

[source c++]GameObject::~GameObject(){	//delete this->dpSquare;	//delete this->atSquare;}



You mentioned it might have been something about the pointer not being there or something so i commented that out.
Visual Studio 2008Visual C++SFML
dpSquare;
atSquare;

I take it these each have a corresponding new right? Is your class or those pointers duplicated or handled in some other odd way?
If the memory they point to is created by new is it new X; or new X[Y];?

The assert fail you have is (in my experience) most often caused by freeing memory via pointer multiple times (delete []) or by deleting something that is a pointer to something not allocated by new.

You would need to provide a lot more code for people to explain the problem. Specifically to begin with the full constructor and destructor as well as the class definition would be beneficial.
Additionally to what empirical2 said:

Are you storing your GameObjects in an STL container? If so, are you following the rule of three? (e.g. having copy, assignment and destructor properly defined)

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

It basically means you aren't following the rule of three. If you need help understanding how to follow the rule of three in this instance, just ask.

When you get abort/retry/ignore, the best option is to attach the debugger and then click retry.
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

This topic is closed to new replies.

Advertisement