Crash on exit while attempting to write font
by Sim Ops Studios (#0002) · in Torque Game Engine Advanced · 09/13/2007 (8:05 am) · 1 replies
Hi all,
We are experiencing a crash-on-exit with TGEA (occurs in 1.01 and 1.03).
Specifically, we are crashing in the destructor for GFont when it calls its own write() method, which I believe has to do with writing the font into the font cache at shutdown. write() loops through the texture sheets in the font, and attempts to write the bitmap defining each texture into a PNG stream.
However, when this problem occurs, the bitmap contained within the one-and-only texture sheet is a null pointer, and therefore there is a crash when attempting to do anything with it. Tracing this problem backwards, I found that the bitmap used to exist, but had been deleted properly by the kill() method of the texture. Tracing backwards further, the reason that the texture had been killed was that Platform::shutdown() was called from main.cpp. This of course is perfectly logical since we are shutting down...
The problem appears to be that ResManager::destroy() is called AFTER Platform::shutdown() in main.cpp; all of the GFont objects are destructed when destroying the ResManager, but by this time, Platform::shutdown() has already killed off the bitmaps that the fonts are pointing to... but the texture objects themselves still exist.
I am not sure what the 'proper' way to fix this is, or if perhaps we are doing something wrong that gets things into a weird state where this becomes possible. It is interesting to me that this only occurs sometimes- I have a sequence of events that can reproducibly get our program into a state where this happens, but I'm unsure what it is about this sequence of events that triggers it.
I could have GFont check to see if the bitmap object still exists, before it tries to write it out, which is probably a good safeguard in any case, but it feels like there is a deeper issue here with the order in which things are being destructed.
Any insight into this problem, anything that could point us in the right direction of finding a cause or solution, would be greatly appreciated!
Thanks,
-lem
We are experiencing a crash-on-exit with TGEA (occurs in 1.01 and 1.03).
Specifically, we are crashing in the destructor for GFont when it calls its own write() method, which I believe has to do with writing the font into the font cache at shutdown. write() loops through the texture sheets in the font, and attempts to write the bitmap defining each texture into a PNG stream.
However, when this problem occurs, the bitmap contained within the one-and-only texture sheet is a null pointer, and therefore there is a crash when attempting to do anything with it. Tracing this problem backwards, I found that the bitmap used to exist, but had been deleted properly by the kill() method of the texture. Tracing backwards further, the reason that the texture had been killed was that Platform::shutdown() was called from main.cpp. This of course is perfectly logical since we are shutting down...
The problem appears to be that ResManager::destroy() is called AFTER Platform::shutdown() in main.cpp; all of the GFont objects are destructed when destroying the ResManager, but by this time, Platform::shutdown() has already killed off the bitmaps that the fonts are pointing to... but the texture objects themselves still exist.
I am not sure what the 'proper' way to fix this is, or if perhaps we are doing something wrong that gets things into a weird state where this becomes possible. It is interesting to me that this only occurs sometimes- I have a sequence of events that can reproducibly get our program into a state where this happens, but I'm unsure what it is about this sequence of events that triggers it.
I could have GFont check to see if the bitmap object still exists, before it tries to write it out, which is probably a good safeguard in any case, but it feels like there is a deeper issue here with the order in which things are being destructed.
Any insight into this problem, anything that could point us in the right direction of finding a cause or solution, would be greatly appreciated!
Thanks,
-lem
About the author
Sim Ops Studios (#0002)
Default Studio Name
We've tracked the 'trigger' for this crash down to a single line of TorqueScript code; actually it is more like we stumbled randomly across the line of code, as one of the programmers removed it for another reason and the crash disappeared.
The specific cause was calling Canvas.clear() from TorqueScript - any time this is called, we experience the crash on exit. The code was written a while ago, but I think that the intention of that code was to clear all the Gui controls off the canvas before calling setCanvas to load a different set of controls. In retrospect, this appears to be unnecessary, and we realized that and removed the code- thus revealing the cause of the crash.
Presumably clearing the Canvas SimSet altered the sequence of events at shutdown, causing the font texture to be destroyed before the GFont object.
My question then would be, is it ever valid to call clear() on the Canvas? I can't think of a good reason to do it, but someone new to Torquescript might think otherwise (clearly we did!) so perhaps it should be noted somewhere that it is a Bad Idea?
Thanks,
- lem