Hi Philip, You may be having a similar problem that we were having recently. Before you dlclose be sure to call these functions as all the osg examples do:
// wait for all cull and draw threads to complete. viewer.sync(); // run a clean up frame to delete all OpenGL objects. viewer.cleanup_frame(); // wait for all the clean up frame to complete. viewer.sync(); Assuming you are using the viewer class. Zach -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Lowman Sent: Thursday, December 07, 2006 11:37 To: osg users Subject: Re: [osg-users] using OSG as a plugin with dlopen() and dlclose() Robert Osfield wrote: > Hi Philip, > > You should use the osgDB for opening and closing plugins. In > osgDB::Registry you'll find: > > /** find the library in the OSG_LIBRARY_PATH and load it.*/ > bool loadLibrary(const std::string& fileName); > > /** close the attached library with specified name.*/ > bool closeLibrary(const std::string& fileName); > > This way you'll ensure that all the OSG data structures that it sets > up related to the plugin are cleaned up and the code will be 100% > portable. I did try a loadLibrary and closeLibrary on osgdb_osg.so which I think is the only plugin that would be used by readNodeFile("blah.osg") call. I don't think this matters though as what I'm trying to do is use the entire OSG as part of a dynamically loaded plugin (not implement an OSG plugin). Basically the idea is to use OSG within an alternative terrain lookup plugin. This has a number of advantages like not requiring OSG to be installed in order to use the base capabilities of our simulation framework. To implement this we have a plugin that we dlopen() that links against osg and osgDB. This works great, the only problem we're having now is that calling dlclose() on our plugin leads to a segfault. The segfault only happens after a readNodeFile() call in the plugin though. Commenting out this call fixes the problem which leads me to believe that something in OSG might not be cleaning itself up properly. Here is a stack trace of my example code with debugging libraries for OSG 1.2 (just got them compiled). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210787648 (LWP 2897)] 0xb79a8143 in ?? () (gdb) bt #0 0xb79a8143 in ?? () #1 0x08066170 in ?? () #2 0x080486cc in [EMAIL PROTECTED] () #3 0xb6b3dec8 in ?? () #4 0x048a36a6 in ?? () #5 0xb6b4a39b in ?? () #6 0x00000016 in ?? () #7 0x00000018 in ?? () #8 0x0804a330 in ?? () #9 0x080666cc in ?? () #10 0xb7a3f8fc in ?? () #11 0xbf83c308 in ?? () #12 0xb7c79554 in ?? () #13 0xb79efc90 in ?? () #14 0xb7fccce0 in _dl_argv () from /lib/ld-linux.so.2 #15 0xb7faf724 in ?? () #16 0x080666b8 in ?? () #17 0xb6f90cd9 in pthread_mutex_unlock () from /lib/tls/i686/cmov/libpthread.so.0 Previous frame inner to this frame (corrupt stack?) -- Philip Lowman Simulation Development Engineer, Modeling and Simulation Technology General Dynamics Land Systems http://www.gdls.com _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
