What I ended up doing was breaking down Scarlet and sort of starting over, except most of the code was already written. As I slowly rebuilt it I carefully went over every class already written, checking things like copy constructors, desctructors, and anything else where weird stuff can happen. I did end up creating a few copy constructors, they were all for classes with just primitives in them (not my memory leak problem). The only major thing I did was make it so Scarlet is no longer a singleton class. Fortunately the only things I've done with Scarlet are Car That Drives to the Right, and a skeleton framework for Squarediana Jones, so refactoring them was easy.
When I finally got back up to the Sprite stuff (where the crashing problem was happening), I started it up and what do you know... no problems.
Now, this is with the exact same sprite code as before, I mean it was literally the same file as before, just copied from my bkp directory to my working directory. This is how I know there was a mutant vortex of impossibility.
I'd also like to note that before rebuilding Scarlet, I did to a clean build and all that other fun stuff, so no sucky .o files were lying around causing things not to fix themselves or whatever.
So this got me back up to the point I was at when looking for the memory leak.
Using CarRight as a testbed, I re-began my search, and guess what... ok it's pretty obvious, but yeah, I found it.
Want to know what it was?
Way back in the day, when I started the SnakeEngine projects, I made a decision that all GraphicEntity classes would need a bool initialize(void) method. And thus, they all do. To add a GraphicEntity to the list of things to be displayed my Graphics class has a method void addToDisplay(GraphicEntity* ent). Now, before adding things to the list, it checks if the entity is initialized, how? With this: if(ent->initialize()). See a problem here?
Two things:
1.
initialize returns a bool, a success notifier.
addToDisplay returns void, if there is a problem the bool doesn't get propogated back to anywhere useful.
2.
Say the GraphicEntity is already initialized, then I expected for the entity itself to check for that, and do nothing but return true when that method is called. What if I forget to do that for a GraphicEntity? BAM, possible memory leak, depending on what goes on in initialize. This is exactly what was happening.
3.
WHY SHOULD addToDisplay INITIALIZE OBJECTS?! IT JUST SAYS IT ADDS! STUPID!
Anyway, my reasoning for that was in case the programmer (uh..me) forgot to call the GraphicEntity's initialize method, it would still be ok. This decision always left a bad taste in my mouth because I knew it was a bad thing to do, but it worked so I left it in. Now it's gone.
So anyway, now I can add and delete missiles all day long in Car That Drives to the Right and no memory leaks. Graphics is no longer a singleton, and the code is a bit cleaner (it really wasn't bad to begin with, even have comments) and hopefully more robust (I changed a few things here and there along the way).
Scarlet is a go, let's make some games.
