Hi Timo, Could you explain what you've done in more fine grained steps so that others will be able to understand what approach you've taken so that when they try the same thing they don't need to go through the same learning curve.
Thanks, Robert. On Mon, Jun 2, 2008 at 6:44 AM, Timo Penndorf <[EMAIL PROTECTED]> wrote: > Hi Paul, > Hi Robert, > > thank you for your answers. I solved my problem. dlopen provides > the RTLD_NODELETE flag and for windows I found a related article > (http://msmvps.com/blogs/vandooren/archive/2006/10/09/Preventing-a-DLL-from-being-unloaded-by-the-app-that-uses-it.aspx) > which finally results in incrementing the reference counter of > the plugin-dll twice. As it is implemented in the plugin its author > could decide whether it is necessary or not. > > So my application works fine on both intended platforms now. > > Timo > > > > > Am Sonntag, den 01.06.2008, 16:00 +0100 schrieb Robert Osfield: >> 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 > -- > +--------------------------------------+ > | | > | Dipl.-Ing. Timo Penndorf | > | | > | Institut für Verarbeitungsmaschinen | > | und Mobile Arbeitsmaschinen | > | | > | Technische Universität Dresden | > | 01062 Dresden | > | | > | Tel: 0351 463 34972 | > | Fax: 0351 463 37731 | > | | > +--------------------------------------+ > > > +--------------------------------------+ > | | > | Dipl.-Ing. Timo Penndorf | > | | > | Institute of Processing Machines | > | and Mobile Machinery | > | | > | Dresden University of Technology | > | D-01062 Dresden | > | | > | Tel: 0049 351 463 34972 | > | Fax: 0049 351 463 37731 | > | | > +--------------------------------------+ > > > _______________________________________________ > 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
