Hi Paul, Destructing the Viewer should be enough to get the rendering backend (RenderStage/StageGraph etc) to clear, there shouldn't be any need to let the viewer keep rendering for a couple of frames. Unless of course you still needed the viewer after the, if so perhaps a clear method would be appropriate...
In Timo's case I would guess that destructing the Viewer would be part of the work of uloading all the OSG libs. Robert. On Sun, Jun 1, 2008 at 3:36 PM, Paul Martz <[EMAIL PROTECTED]> wrote: > 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 >> > [email protected] >> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. >> > org >> > >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
