[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