[omniORB] deadlock in omniORBpy-3

[Luke Deller]

Hi,

In a python extension written in C, I call CORBA::Object_var's
destructor while holding the python interpreter lock.  This has worked
fine in the past, but now with omniORBpy-3.0/omniORB-4.1.0 it produces a
deadlock.  Is this supposed to work, or is it expected that I should
release the python lock before releasing C++ CORBA object references?

The following stack traces of two threads show how the deadlock occurs:
--- thread 1:
#0  0x00002afa07fbc1bd in sem_wait () from /lib/libpthread.so.0
#1  0x00002afa07e2f063 in PyThread_acquire_lock (lock=0x57e020,
waitflag=1) at thread_pthread.h:313
#2  0x00002afa07dfbfbe in PyEval_AcquireLock () at ceval.c:228
#3  0x00002afa08e36014 in omniPy::Py_omniServant::_add_ref () from
/usr/lib64/python2.4/site-packages/_omnipymodule.so
#4  0x00002afa090a05d4 in omni::omniOrbPOA::servant__this
(this=0x91b510, p_servant=0x37e3f50,
   repoId=0x2afa0911967d "IDL:omg.org/CORBA/Object:1.0") at poa.cc:2439
#5  0x00002afa090ace1a in PortableServer::ServantBase::_do_this
(this=0x37e3f50,
   repoId=0x2afa0911967d "IDL:omg.org/CORBA/Object:1.0") at
portableserver.cc:346
#6  0x00002afa08e36bd5 in omniPy::Py_omniServant::py_this () from
/usr/lib64/python2.4/site-packages/_omnipymodule.so
#7  0x00002afa08e2d09e in pyPOA_servantThis () from
/usr/lib64/python2.4/site-packages/_omnipymodule.so
#8  0x00002afa07dbddd5 in PyCFunction_Call (func=0x2afa08ccb3b0,
arg=0x2aaab0508790, kw=0x0) at methodobject.c:73
#9  0x00002afa07e04814 in call_function (pp_stack=0x4a00d0d8, oparg=1)
at ceval.c:3563
#10 0x00002afa07e012a7 in PyEval_EvalFrame (f=0x9e6540) at ceval.c:2163

--- thread 2:
#0  0x00002afa07fba566 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x00002afa0928e01d in omni_condition::wait (this=0x884278) at
posix.cc:163
#2  0x00002afa090b2091 in omni_tracedmutex::lock (this=0x884250) at
tracedthread.cc:188
#3  0x00002afa0905c080 in omni_tracedmutex_lock (this=0x45807a00,
m=@0x884250) at tracedthread.h:152
#4  0x00002afa09085def in omni::releaseObjRef (objref=0x2aaab1605c10) at
omniInternal.cc:525
#5  0x00002afa0a3abb76 in CORBA::release (o=0x2aaab1605bf8) at
CORBA_Object.h:157
#6  0x00002afa0a3abb20 in ~Object_var (this=0x45807ac0) at
CORBA_Object_vartypes.h:71
(Python GIL held)

Looking at the code, it seems that calling pyservant._this() in python
results in the following sequence:
(1) the python GIL being released
(2) the omniORB internal lock being acquired
(3) the python GIL being acquired

It seems surprising to me that the python GIL would be acquired while
the omniORB internal lock is held.

I didn't see any change to this code since omniORBpy-2.7/omniORB-4.0.7,
so I'm not sure why this problem has only arisen for me with
omniORBpy-3.0.

Thanks,
Luke.