[omniORB] Bug in omnithread when using dlopen/dlclose (Well maybe!)
Mark Hole
mark.hole@futuretv.com
Thu, 16 Nov 2000 16:25:13 -0000
Hi all,
Caveat : I've only just started using omniorb so it may be that I have done
something stupid! Also apologies if this has been noted before by someone
else.
Platform: Linux Debian-potato
Omniorb : 3.0.2
Symptom:
I have a shared library 'xyz.so' which implements the client side of a corba
call (therefore links to libomniORB3.so, libtcpwrapGK.so and
libomnithread.so.
In another app I dlopen the 'xyz.so' library.
I immediately dlclose the 'xyz.so' library (note without having called any
methods on it - and by implication any omniorb methods).
The dlclose exits with success followed momentarily later by a segfault in
the application.
Possible Cause:
Omnithread.h defines a class omni_thread::init_t along with a static
instance of it to do some pre main initialisation within the classes
constructor. This initialisation includes the creation of both an
omni_thread and an omni_mutex.
I would suggest that the problem is that there is no destructor for the
omni_thread::init_t class thus the omni_thread created earlier still exists
and gets upset by the rug being pulled from under it.
Possible Solution:
Creating a destructor for omni_thread::init_t which tidies up seems to have
solved the problem for me.
------------------------
I would really appreciate it if someone could sanity check what I am
suggesting or alternatively tell what I may be doing wrong / what the true
fix is.
Many thanks
Mark Hole
FutureTV Systems Ltd.
mark.hole@futuretv.com