What is likely happening is that the BitmapFont is not copyable. That is, when you create a copy, and the copy goes out of scope, it destroys resources that the "original" is also using.
Ahhh... of course, that makes sense. I should have noticed that possibility myself.
Now just checking the destructor... if I comment out the destructor of the underlying SpriteSheet object then it does stop happening. Yay.
Thanks for tracking that one down. Left me quite confused for some time.
Yes... I see what it ultimately leads to now; the GLuint variables referring to the texture and sampler get deleted when the texture wrapper class goes out of scope, and the VBOs of SpriteSheet do likewise.
As for a solution... I've been trying to think this through... and doing the ordinary deep copy of a pointer seems like it wouldn't be very straightforward. Am I right in thinking that to give a copy its own copy of the texture (and thereby allow it to release that texture on destruction), you'd have to go through loading the whole texture again, or is there another way in OpenGL?
Would it be better to work around it instead, and remember never to copy these classes like that? i.e. Just keep using my method of creating a new GameDateTime object with the same values as the current one. Sounds like bad practice to leave such a potential bug lying around, but the other way seems kind of elaborate and maybe wasteful to me.
The only other option I can foresee is giving it some way of knowing if a texture is in use, and only selectively deleting it if nothing else is using it. Not sure how practical that would be. Maybe it would work by incrementing some counter when the copy constructor is called, and then decrementing it on destruction? Feels kind of sloppy to me though and like it might be covering up bad design.
Or am I just tired and the solution is much simpler and more obvious than I realize?