<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello,<div>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.</div><div>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:</div><div><br></div><div><div>#0  0x00007fa9c605b54d in __lll_lock_wait () from /usr/lib64/libpthread.so.0</div><div>#1  0x00007fa9c6056e9b in _L_lock_883 () from /usr/lib64/libpthread.so.0</div><div>#2  0x00007fa9c6056d68 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0</div><div>#3  0x00007fa9c6522ab3 in CORBA::ORB::_nil() () from /usr/lib64/libomniORB4.so.2</div><div>#4  0x0000000000d8a09e in ORB_var (this=0x7fa9940008c0) at /usr/include/omniORB4/CORBA_vartypes.h:167</div><div>#5  Components::MarketServer::ClientInterface::ClientInterface (this=0x7fa9940008c0) at ./CorbaFiles/CorbaClient.cpp:20</div></div><div>....</div><div><br></div><div>Looking at the OmniORB source code, we narrowed the cause to the omni::nilRefLock() method:</div><div><br></div><div><div>omni_tracedmutex&</div><div>omni::nilRefLock()</div><div>{</div><div>  // We are safe just testing this here, as we guarentee that</div><div>  // it will be initialised during the static initialisation.</div><div>  // (Which is single-threaded).  If not by this method, then</div><div>  // by the static initialiser below.</div><div><br></div><div>  static omni_tracedmutex* nil_ref_lock = 0;</div><div><br></div><div>  <b>if( !nil_ref_lock )  nil_ref_lock = new omni_tracedmutex("nil_ref_lock");</b></div><div>  return *nil_ref_lock;</div><div>}</div></div><div><br></div><div>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</div><div>that is corrupted and is never unlocked.</div><div><br></div><div>Not sure if this is a bug of the OmniORB library or a wrong initialization of the ORB_var instance.<br></div><div>Any help will be appreciated.</div><div><br></div><div>Thanks and regards,</div><div>Davide Rosso</div></div></div></div></div></div>