Hi Philip,
What you are doing is along way off designed usage of the OSG, but the
OSG being just C++/OpenGL is "should" be possible. The problem you
probably have is down to a order issue with unloading of libraries -
start by unloading all the plugins (use osgDB for this), then the next
highest OSG library in the depdency chain till you get down to the
unloading the core OSG itself.
Robert.
On 12/7/06, Philip Lowman <[EMAIL PROTECTED]> wrote:
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/
