Don't know if anyone will find any of this interesting but I figure I might as well take the opportunity to vent about the non-sense my own code inflicted upon myself.
The line where the error would occur was
CSwooshEffect * pItemTemp = new CSwooshEffect;
From this line I experienced weeks of being confronted with "Windows has triggered a breakpoint in [program].exe". Google searches that all pretty much say the same thing when other people ask about it, "You're probably writing to memory that's already been freed." I figured I'd get about the same response if I posted a question here or anywhere so I began painstakingly started going through code to try to find such a situation. I plugged in Paul Nettle's MMGR code into my project which helped find the source of a bunch of leaks. But after fixing them, that damn message still came up even though the leak report came back "No memory leaks found!" Clearly I didn't really have them all. But I just couldn't understand it. All I was doing was instantiating a new object, how could that be writing to memory that's been freed?
Trying to battle that one message resulted in me rewriting my animation class that I've been using for almost a decade now, it resulted in finding 2 other locations causing leaks, revealed that I forgot to change some code for a few objects so they're created using new() instead of being members of another class, it resulted in the realization that some sorts I'm doing on my object lists weren't sorting correctly. I found a variety of things I was doing wrong and yet despite all that the message wouldn't go away.
As fascinating as I'm sure all this is, I'll skip ahead now to where the problem finally was. (my dev notes have the details of how I came to this point, I can post them if anyone's interested but I'll skip ahead).
I keep a few lists that are used to track instances of objects. I was investigating a tile's list of objects and comparing it to a main list of objects. Checking that an object was being created and being properly set to the tile's list of objects. I wanted to make sure that everything was the same when that object's pointer later got removed from the tile's list and the object deleted. The object itself was indeed the same however completely by chance I noticed that the tile that I thought was working with wasn't actually the one I was working with. It all went a little something like this:
- From my main list I'd determine which object required deletion.
- Using the object's world co-ordinates I'd calculate what tile that object was associated with.
- This calculation was producing a rounding error causing me to look at the wrong tile's object list.
- The wrong list of objects isn't actually affected.
- The object is removed from the main list.
- The object is finally deleted from memory.
- The tile with the list that should have been examined now has a pointer in it pointing to freed memory.
That memory gets accessed later on in my paint routine. Undefined behavior due to accessing invalid memory sounds like an appropriate description of the trouble I've been having.
I dealt with the problem by adding the tile co-ordinates that the object is on to that object. Not terribly creative but it got the job done.
This annoying issue has taken so much attention I don't know what's next now.
