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/
