I posted to this list about a similar issue not too long ago. I have a MS Windows application that creates a subgraph in a DLL. After rendering the subgraph for a while, due to some user interaction the subgraph is removed. The application was then immediately unloading the DLL that created the subgraph, thinking it should certainly be safe to do so.
However, we encountered the following behavior: OSG's rendering backend (RenderLeafs, etc) still had some ref_ptrs into the removed subgraph, and didn't relinquish those ref_ptrs until a couple of frames later. Unfortunately, unloading the DLL also deleted the heap that was used to allocate the subgraph, so when those ref_ptrs finally decremented the reference count, the memory was already deleted -- crash. (This was on Windows; shared lib and heap behavior might be different on other OSes.) The final workaround was to allow the app the render a few frames (with the subgraph removed) and wait until the app was quiescent before unloading the DLL. So, I wonder if it might help you to unload your entire scene graph, then render a few empty frames before unloading your shared library. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Robert Osfield > Sent: Sunday, June 01, 2008 4:28 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] correct manual shutdown of osg libraries > > Hi Timo, > > I have never tried this first hand so can't comment with > great wisdom, best I can do is guess. Destructing the > osgDB::Registry in the way you have "should" close all the > OSG plugins that have been loaded. In your instance a > destrucutor of a core OSG node is crashing, which suggest to > me that something like the core osg library has been unloaded > before osgDB::Registry::instance() has been destroyed. Might > this be the case? > > The best I can suggest is that you shut down all OSG released > threads, then unload the plugins, then the viewer then > NodeKits then core osg libries such osgDB then osgUtil then osg. > > Robert. > > On Sat, May 31, 2008 at 1:41 PM, Timo Penndorf > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > for my application I have written an osg plugin which is loaded > > dynamically via dl_open. This plugin is linked against the osg > > libraries and adds visualisation capabilities to my application. > > > > At application shutdown I remove all loaded plugins by dl_close. > > As the osg plugin is the only one linked against the osg libraries > > they are removed from address space ass well after removing the > > plugin. > > > > So my application runs into trouble at __cxa_finalize(). There are > > still some osg::ref_ptr objects in adress space but the > code for the > > destructors is removed already. I suppose the osg::ref_ptr objects > > which are alive at __cxa_finalize are static objects (for instance) > > from singletons. > > > > I tried to clean up then osgDB::Registry manually by invoking > > osgDB::Registry::instance(true) but there are still some > cases where > > the application runs into core dumps. > > > > Is there a chance to remove static objects to prevent my > application > > from producing segmentation faults? > > > > Timo > > > > > > The gdb output: > > > > #0 0x00000000 in ?? () > > (gdb) up > > #1 0x003ba6d3 in osg::Referenced::unref (this=0x8bb3c28) > > at /usr/include/osg/Referenced:142 > > 142 OpenThreads::ScopedLock<OpenThreads::Mutex> > > lock(*_refMutex); > > (gdb) up > > #2 0x039bf129 in > osg::OcclusionQueryNode::~OcclusionQueryNode$delete () > > from /usr/lib/libosg.so.35 > > (gdb) up > > #3 0x00a6ade9 in osgDB::DotOsgWrapper::~DotOsgWrapper$delete () > > from /usr/lib/libosgDB.so.35 > > (gdb) up > > #4 0x0502e6fc in ?? () from /usr/lib/osgPlugins-2.4.0/osgdb_osg.so > > (gdb) up > > #5 0x006fe907 in __cxa_finalize () from /lib/libc.so.6 > > (gdb) up > > #6 0x04ff8dd4 in ?? () from /usr/lib/osgPlugins-2.4.0/osgdb_osg.so > > (gdb) up > > #7 0x0506ff20 in ?? () from /usr/lib/osgPlugins-2.4.0/osgdb_osg.so > > (gdb) up > > #8 0x00000050 in ?? () > > > > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. > > org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
