Bug 56226

Summary: crash on game destruction
Product: [Applications] boson Reporter: Andreas Beckermann <b_mann>
Component: generalAssignee: The Boson Team <boson-bugs>
Status: RESOLVED FIXED    
Severity: crash    
Priority: HI    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:

Description Andreas Beckermann 2003-03-22 03:13:48 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:          Linux

Hi
I've had problems with destruction for a veeery long time now - even with system freezes (as most of you know).
I've now spent (again) several hours on hunting the bug - and I think this time I succeeded.

I've minimized boson code to about 1200 lines of code and still have the crash. It is a combination of a driver bug with a lot of textures and a KMainWindow derived widget.
This does *not* happen with QMainWindow and it doesn't happen with low numbers of textures either. Also this bug isn't 100% reproducable - it crashes in about 8 of 10 times I'd say.
The backtrace is kind of unusable - my debug code in BosonGLWidget says basically the same. The bt displays functions from my graphics card (i.e. tdfx functions), so it does *always* crash in the graphics card driver and therefore isn't really a boson bug (thats why it is so hard to hunt it).

It seems (!!) that the problem disappears  when the texture array is deleted correctly (manually). My test code just loads an array of 1244 dummy images in a KMainWindow derived widget (with a BosonGLWidget embedded) and does nothing else. When I delete the array in the destructor of the KMainWindow derived widget (and therefore before the GL widget!) everything works fine (btw: it also works fine if the GL widget has a NULL parent).

I just checked that and it seems that we currently do *not* delete the texture array before we delete the big display. As the big display is the only widget with a GL context we would have to do that.
We will either have to delete *all* textures and display lists when the big display is deleted, or we could try to add a hidden GL widget, which shares the GL context. I am not sure if that would actually work with all GL data (texture objects, display lists, ...) but it is worth a try, as that would be an easy solution. Deleting all data on destruction would pretty much suck - I want to reuse the data when a different map is started.
(btw: this isn't possible when we delete the GL context anyway!)

Another solution to keep re-using the data is to simply never delete the big display. This is the cleanest solution, but might be a bit harder.
I wanted to do that anyway for quite some time now - most work is done already (we have Input classes, which do some game relevant actions) but I think there is more left. To keep the big display alive until the end of the game (I mean: the end of the program) we would have to make the big display completely independant from any game data, i.e. it mustn't store anything directly (lists might work, as we can easily clear them. display lists and textures are not allowed, the same is valid for pointers to Unit or Player).

Both solutions would also fix #56106, which seems (!) to be related. I can't say whether it is related, before I am sure that it doesn't crash anymore once it is fixed.


As I believe I have found the problem for my crashes now (and I am able to solve that in boson without touching the graphic card driver) I file this as a bug now.
It will get high priority, as 50% of our coders don't know any bug that might be more important than this one, and the same 50% of our coders consider this a release critical bug.

CU
Andi
Comment 1 Andreas Beckermann 2003-03-23 03:53:50 UTC
It seems this is actually fixed now. 
I have chosen the cleanest solution (what a surprise ;-)) and haven't had a single crash 
anymore. Finally I can successfully quit boson :-))) 
 
CU 
Andi