Race condition in ORB_var initialization ?

Hello,
we are facing strange behaviour in one of our CORBA clients; the CORBA
client is a multithreaded C++ application in which each thread has an
instance of a class that contains a private ORB_var instance.
What happened is that one of the threads froze in the initialization phase:
killing the process with a -11 signal we examined the core dump in gdb and
found the following stack trace:

#0  0x00007fa9c605b54d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1  0x00007fa9c6056e9b in _L_lock_883 () from /usr/lib64/libpthread.so.0
#2  0x00007fa9c6056d68 in pthread_mutex_lock () from
/usr/lib64/libpthread.so.0
#3  0x00007fa9c6522ab3 in CORBA::ORB::_nil() () from
/usr/lib64/libomniORB4.so.2
#4  0x0000000000d8a09e in ORB_var (this=0x7fa9940008c0) at
/usr/include/omniORB4/CORBA_vartypes.h:167
#5  Components::MarketServer::ClientInterface::ClientInterface
(this=0x7fa9940008c0) at ./CorbaFiles/CorbaClient.cpp:20
....

Looking at the OmniORB source code, we narrowed the cause to
the omni::nilRefLock() method:

omni_tracedmutex&
omni::nilRefLock()
{
  // We are safe just testing this here, as we guarentee that
  // it will be initialised during the static initialisation.
  // (Which is single-threaded).  If not by this method, then
  // by the static initialiser below.

  static omni_tracedmutex* nil_ref_lock = 0;

  *if( !nil_ref_lock )  nil_ref_lock = new
omni_tracedmutex("nil_ref_lock");*
  return *nil_ref_lock;
}

It seems that if the highlighted line is executed in parallel by tho
threads, one of the threads may end up with a pthread_mutex instance
that is corrupted and is never unlocked.

Not sure if this is a bug of the OmniORB library or a wrong initialization
of the ORB_var instance.
Any help will be appreciated.

Thanks and regards,
Davide Rosso

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list