[SOLVED] Problems with order of destruction

In my app, I create a mesh from a manual object. Then after a simple main loop that draws the mesh succesfully, I execute "del mesh" shortly followed by "del app". This crashes when the real mesh destructor is called much later, because all the Ogre singletons have been de-initialized.

Now this approach has worked fine in a lot of my earlier tests, but now I'm doing something slightly more complex (procedural skinning) it crashes. I presume there's a leaked reference to a mesh somewhere...

So I have a few questions:

1) It is possible to track down where the leaked reference is? (There's no obvious place in the code where this could happen.)
2) How can I force PyOgre to delete that object when I know the application is going to exit?
3) What's the recommended way of dealing with such issues so that python doesn't crash when destroying Ogre objects in the wrong order?

Any insights would be greatly appreciated!
Alex

Getting the very latest OgreException.i and rebuilding PyOgre from SVN makes the problem invisible. I presume the exception thrown on destruction is just ignored...

I think it's an acceptable solution, but if you have any thoughts on the original dilema, then please feel free to share!

Thanks,
Alex

After a lot of playing around, there's no easy way to control the order of destruction of the SWIG objects and nor, for that matter, is there a way to control the way python calls __del__ when garbage collecting.

The best solution is to have a shutdown() functions written as a counterpart to __init__() that you call manually in the correct order. There, you have to make sure that all memory is freed on the spot, so that any SharedPointer deleted later by SWIG does not rely on the Ogre singletons that have long been de-initialized. To free the memory call all the specific ResourceManager::unloadAll() implementations, then call ResourceManager::removeAll() to reduce the number of dangling references as much as possible...

I hope this helps someone.

Alex