From: Marcus L. <ma...@ya...> - 2008-11-27 13:15:59
|
(I think I've got it! :) Carsten Neumann wrote: >> (Also, are the MTRefPtr's nulled in their dtor? I don't think so. >> Perhaps that's a good idea to avoid accessing stale objects?) > > yes, I've tried that and it prevents the crash, because the assignment > in subRefDefaultMaterial simply does nothing. However, the assignment > itself makes use of the _defaultMaterial pointer object, which is (or at > least seems to be) dead at that point. So setting the MTRefPtr::_pObj to > NULL solves the crash (at least for me), but still operates on an > destroyed object, which is an even more subtle issue. I agree. >> Hm, I'll have to run the debugger a bit myself I think. :) > > This is an interesting problem, if you find out anything please let me > know, I appreciate your help in getting to the bottom of this. Stepping in the debugger clearly says that the _defaultMaterial ptr gets destructed (by the static initializer's atexit) before the subrefdefaultmaterial() function is called by osgExit(). Which goes against the standard and how we thought it would behave! After stepping through things and looking carefully at the call stack, it seems as if atexit() calls are bunched per dll, which explains the current behaviour: OSGSystem.dll (with has it's statically intialized defaultmaterial) is deallocated before OSGBase.dll (which gets the atexit(osgexit)). Doing like that seems way too crazy though, unless there is something wrong with the linking to runtime libs, so that each dll gets it's own atexit-list. Additionally, the MSDN C runtime library reference says: "The code in the atexit function should not contain any dependency on any DLL which could have already been unloaded when the atexit function is called." Not that it helps, really. So, the osgexitwarpper() gets called after osgsystem's atexit-functions (which includes static initalizations) have been run. ** google c++ dll atexit ** http://www.stevejay.net/coding_article_quitting_time.html Looking at the list in section 3, it seems as if this is indeed the behaviour for msvc and dynamic libraries (of which the c++ standard says nothing). Doh! How to fix that? Simply don't use static MTRecPtr's? That ought to be safe, no, since the subrefmaterial()-functions are always called by osgexit()? Cheers, /Marcus |