Jerry584894

Upon exiting, my program comes up with an assertion error. It says:

Debug Assertion Failed!

Program:...

File: dbgdel.cpp

Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->BlockUse)

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

Abort Retry Ignore

So... Apparently it has to do with me deleting a pointed object. I've tried delete-ing a reference to it, but it didn't work. It is part of a prsn class which contains a pointer to a item class, and the deleting is where the breakpoint occurs... Why is this happening




Re: Visual C++ Language Assertions...

Sdi

If you're trying to delete a member *object* of a class object, that won't work. If the class object contains a *pointer* to heap memory, you'll delete that when the object is cleaned up, but a non-pointer member is not separately delete-able. If it's really a pointer, make sure you aren't delete-ing it twice. Use "Retry" to break into the debugger and follow the call stack up to see who's delete'ing the object.



Re: Visual C++ Language Assertions...

Jerry

I'm not sure what heap memory is, but I realize that all the prsn objects are pointing to one item object, and I'm using deleting all of the pointers... Which I think might be the problem I will try that now. Thanks!




Re: Visual C++ Language Assertions...

Jerry

So it has worked, and I hope that it is not causing memory leaks...

Is it






Re: Visual C++ Language Assertions...

crescens2k

If what you said above is true then the problem you were having was caused by trying to delete a pointer more than once. As far as memory leaks are concerned just follow the general rule of one delete/free for every new/malloc.

There is a method of detecting unfreed memory and that is _CrtDumpMemoryLeaks. You should look this up in the documentation to check how it works. This will tell you if there is any memory still allocated, but be careful because it is also prone to false positives. It tells you about globals too which are deleted later, just as the program is terminated. The best place to put this function call is the very last statement in the main function, just before the return.






Re: Visual C++ Language Assertions...

Sdi

If you're sharing an object among multiple clients, you either need a reference-counting mechanism so that the object is only deleted when everyone is finished using it, or you may need to make it a static or static-equivalent object that is created only once and deleted only once.



Re: Visual C++ Language Assertions...

Jerry

Actually it is just an automatic global which does not get deleted at all (except by destructor, at end of program)... What I am wondering is, do I have to delete every pointer to the item object (the pointers are in the prsn objects) Or do they automatically delete like others Because if they do, then there shouldn't be any memory leak...




Re: Visual C++ Language Assertions...

Sdi

I'm not sure what an "automatic global" object might be; if it's a static global, it probably doesn't need to be explicitly deleted at all.

You don't delete pointers; you delete pointed-to objects. But only if the pointer "owns" the object. Setting a pointer to point to an object doesn't allocate memory. Think of your phone number: how many people have your phone number in their cell phones or speed-dial lists What's the impact on your phone if one of them does a hard reset on their phone and loses your number





Re: Visual C++ Language Assertions...

Shakje

I'm guessing he means an automatic pointer that deletes the object it points to when all references go out of scope. The one thing missing from the analogy is that if you delete the number on your phone it doesn't affect the person's phone but if you delete the object a pointer points to explicitly the object is deleted.

That sort of assertion implies that you're trying to delete an already deleted object. A quick fix might be to NULL pointers after you delete and check for NULL every time you try to access the pointer. If you're only trying to signal that the pointer shouldn't be used any more just NULL it. Only delete an object (using delete and a pointer deletes the OBJECT) when you know you won't use it again.

If you're really using an object that gets deleted at program termination then don't try and delete it manually, possibly the better way of managing pointers would be to use the Boost shared_ptr for all references to the pointer, this will be careful about what is happening with the pointer and is generally safer.






Re: Visual C++ Language Assertions...

Sdi

I think it's fairly clear that the ASSERT is caused by an invalid delete call; the question is whether it's a multiple delete on a heap object, or an attempt to delete a non-heap object. If the object is a global created-at-load-deleted-at-shutdown object, it probably doesn't need anyone to call delete on it at all (though it might need to call delete on heap objects it allocates for itself).



Re: Visual C++ Language Assertions...

Jerry

It's like this:

Code Snippet

#include <item.h>

item sword(1,2,3,4,5,"sword");

\\--blah blah blah blah blah...

main(){

//other initializations

prsn new, other; // each has an item object pointer

new.difitem(sword); // changes item pointer

other.difitem(sword); // to the sword

//... use prsn, item...

}//--both destructors delete the pointer... Is that the problem

//end of file, I think deletes object...






Re: Visual C++ Language Assertions...

Simple Samples

Jerry584894 wrote:

Upon exiting, my program comes up with an assertion error. It says:

Debug Assertion Failed!

Program:...

File: dbgdel.cpp

Line: 52

Expression: _BLOCK_TYPE_IS_VALID(pHead->BlockUse)

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)

Abort Retry Ignore

So... Apparently it has to do with me deleting a pointed object. I've tried delete-ing a reference to it, but it didn't work. It is part of a prsn class which contains a pointer to a item class, and the deleting is where the breakpoint occurs... Why is this happening

Another possibility is that program is writing to memory that it is not supposed to. The macro "_BLOCK_TYPE_IS_VALID" implies it is checking the validity of allocated memory, and the failure indicates that it is not valid.






Re: Visual C++ Language Assertions...

Simple Samples

Sdi wrote:
If you're trying to delete a member *object* of a class object, that won't work.
I see no clue whatsoever that that is relevant.




Re: Visual C++ Language Assertions...

Simple Samples

crescens2k wrote:

There is a method of detecting unfreed memory and that is _CrtDumpMemoryLeaks. You should look this up in the documentation to check how it works. This will tell you if there is any memory still allocated, but be careful because it is also prone to false positives. It tells you about globals too which are deleted later, just as the program is terminated. The best place to put this function call is the very last statement in the main function, just before the return.

Usually, the best way to detect leaks is to do nothing. The defaults will work best in most situations. Just execute a debug build with the debugger and after execution look for errors in the output. If there are memory leaks there will be messages reporting the problem.






Re: Visual C++ Language Assertions...

Simple Samples

Shakje wrote:
A quick fix might be to NULL pointers after you delete and check for NULL every time you try to access the pointer. If you're only trying to signal that the pointer shouldn't be used any more just NULL it.
Except he says he has multiple pointers to one object, and if so, then setting one to NULL won't help when another pointer is used to delete an object that has already been deleted.

Shakje wrote:
If you're really using an object that gets deleted at program termination then don't try and delete it manually, possibly the better way of managing pointers would be to use the Boost shared_ptr for all references to the pointer, this will be careful about what is happening with the pointer and is generally safer.

VC 2005 has a garbage collection feature that I am not familiar with except it probably would be useful too. See the gcnew operator, which is the garbage collection version of new.