[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.

[Teemu Torma]

Post by Luke Deller
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?

I have had to deal this in the past (omniorb-4.0.x/omniORBpy-2.x) when
doing converters of _var variables for Boost.Python. You need to
release the python interpreter lock before calling the release. I
can't remember the details anymore, but my comment says

This is a bit ugly, but for omniORBpy we must release the interpreter
lock before the release is called. The omniorb partial locking order
requires this (omni::internalLock before python interpreter lock), and
release of the var may take omni::internalLock).

I hope this helps.

Teemu

[Luke Deller]

Post by Teemu Torma
I have had to deal this in the past (omniorb-4.0.x/omniORBpy-2.x) when
doing converters of _var variables for Boost.Python. You need to
release the python interpreter lock before calling the release.

Thanks Teemu. I suppose I was just lucky to avoid problems in the past.

I have added a note to the bottom of the UsefulTips wiki page, with the
heading "Avoiding deadlock with omniORBpy in a C/C++ extension module".
This is editable by anyone.

http://www.omniorb-support.com/omniwiki/UsefulTips

Thanks,
Luke.


**********************************************************************************************

Important Note
This email (including any attachments) contains information which is
confidential and may be subject to legal privilege. If you are not
the intended recipient you must not use, distribute or copy this
email. If you have received this email in error please notify the
sender immediately and delete this email. Any views expressed in this
email are not necessarily the views of XPlan Technology.

It is the duty of the recipient to virus scan and otherwise test the
information provided before loading onto any computer system.
Xplan Technology does not warrant that the
information is free of a virus or any other defect or error.
**********************************************************************************************