Assertion failure on exiting program

Crash and debug-build assertian failures on exit are normally a sign that you have corrupted memory in some way. In decreasing order, I find they are usually due to a buffer overrun/overflow, stack corruption, heap corruption, or other memory badness.

Use the CRT debug functions to check for these things, there are many great examples of using it in MSDN. Search for CRTDBG.

frob.

First of all.... why MFC ???? :) (just kidding, use whatever fits you)
Second of all, it might be that somewhere along your app (might be in the new code) you have a memory leak.

I once had the same problem (though can't remember if it was the same line)
that when I exit the app an error like this occurs.
Then after an exausting code debug I have found out that I had memory leaks which after removed, solved the problem .

Thank you for the replies. I had pondered the possibility of a memory leak, I just didn't think any of the new code I wrote would cause one. I'll check with MSDN like you said.
And just for the record, I know most people don't like MFC, but...well, here is the story. I started off in college (2 years ago) a comp sci major at a regional university that offered nothing close to a game programming class. Actually, the only class they offered that involved c++ programming in windows was this MFC course. Up to this point all of my games were text based console titles...not much fun. But the MFC class finally gave me the ability to program games the way I wanted to. My game is a 2d tile based RPG so performance isn't a huge consideration for me. Now I am in Pharmacy school (I sold out) and program only as hobby. I want to learn DirectX or SDL or similar, but I have decided to finish my game first using what I know and the engine that I have already built, which involves a lot of MFC. So that is the long and the short of it.

Thanks again, coby

Quote:

Original post by shadowcomplex Thank you for the replies. I had pondered the possibility of a memory leak, I just didn't think any of the new code I wrote would cause one. I'll check with MSDN like you said.

It probably isn't a memory leak. It is much more likely that you are stomping on memory you don't own (like a buffer overflow).

Example:

// This code makes me cringe.
int array[10];
...
array[10] = 123; // Bad
for( int i=0; i <= 10; ++i ) array = i; // Bad


You're better off using learning how to use the C++ stl properly. This means never making a fixed-length array and never calling 'new' or 'delete'.

frob.

Original post by frob

Quote:

Original post by shadowcomplex It probably isn't a memory leak. It is much more likely that you are stomping on memory you don't own (like a buffer overflow).

Exactly. A memory leak on it's own will do nothing more than make your program consume more memory than it should. (Though that can cause an out-of-memory crash)
Try to follow the advice given about eliminating buffer overruns.

Thanks for the replies. Actually I don't use arrays like that. Although I don't use the stl containers, I have written my own dynamic cstring/carray classes that allocate/deallocate dynamically using new/delete. I am sure the problem is not with these classes because I have used them in virtually every program I have ever written. Since I do not use the fixed-length arrays that work off of the stack, is memory leak still viable, or not?
Thanks again,
coby

This is probebly not memory related at all.

If you call the destructors of objects in Quit(). Maybe those objects are beeing used after that? Since sending a WM_CLOSE wont execute immediatly, but when you next time call Peek/GetMessage(). Probebly some mfc object since it asserts in a mfc header.

Calling destructors by yourself is usualy bad practice. You should let dem be called automaticly when the resource goes out of scope or is deallocated by you.

To rule out a memory leak, you should monitor your track your memory. I strongly recommend using Paul Nettle's MMGR (memory manager). It integrates very easily into projects, and provides a thorough examination of your memory usage.

MMGR can be found on this site: http://www.fluidstudios.com/?freeware

Ok the problem is now solved, but I don't really understand why...
First off, I used Windows task manager to monitor cpu usage during the game and immediately after closing the game down. In game CPU was near 100%, and when I exited and clicked ignore multiple times (and the program didn't completely crash) the game would shut down, but cpu would stay near 100% still, even with no other processes going on. In fact, the code wouldn't even execute again until I restarted my comp and the usage dropped back to the normal 2-4%.

Knowing this I went back and and commented all of the new npc code out, ran the program, and it shut down fine and cpu usage dropped back to normal upon exiting.
After trial and error it turned out two specific things were causing the exit crash, but I am not sure why.

Here is some psuedo code to explain

GameLoop()
{
while(gameon)
{
CheckInput();
CheckNPCs();
...
Render();
}
}

CheckNPCS()
{
CClientDC clientDC(this); //This line would independently cause the error
if(posx==herox)
...
...
enemybitmap.PasteTrans(&enemyLayer,posx,posy,&clientDC); //this one too
}

Render()
{
CClientDC clientDC(this);
enemylayer.PasteTrans(&baselayer....);
herolayer.PasteTrans(&baselayer...);
....
baselayer.Paste(&Screen,...);
}

Creating a CClientDC instance in the CheckNPCS() code would cause the error if everything else was commented out, and then likewise the enemybitmap.pasttrans dependently would too.
Simply not creating the CClientDC instance in CheckNPCS() and moving the enemybitmap.pastrans to the Render() function alleviated the problem. Of course, I should have done this all along but I still don't understand why it caused the assertion failure...

Thanks for all of the help

coby

For some slight clarification my bitmaps are of class CEBitmap, which I wrote a few years back and has been pretty dependable for me.