Deadlock in eventd/ProxyPullSupplier

[Schmidt Thomas]

Hi,

a ProxyPullSupplier deadlocks if more than one pull consumer are
connected to the same event channel. The following stack traces of
two concurrent threads of eventd will illustrate the facts:

At first a pull request from the ProxyPullSupplier site (Thread B).
It gets the mutex 'ProxyPullSupplier_impl::requests' (Thread B, Line
#5).
Now a pull callback on the ProxyPullConsumer site arises (Thread A)
notifying a new event. It locks when trying to forward the event to
our ProxyPullSupplier.
Finally back to Thread B. It continues ProxyPullSupplier_impl::notify
() blocking on its just locked mutex.

Thread A:
#0 0x9002bfc8 in semaphore_wait_signal_trap
#1 0x90001810 in pthread_mutex_lock
#2 0x00013394 in MICOMT::Mutex::lock at pthreads.h:172
#3 0x00013410 in MICOMT::AutoLock::AutoLock at os-thread.h:173
#4 0x0000851c in ProxyPullSupplier_impl::notify at CosEvent_impl.cc:332
#5 0x01028f94 in
CosEventChannelAdmin::ProxyPullSupplier_stub_clp::notify at
CosEventChannelAdmin.cc:675
#6 0x00005030 in EventChannel_impl::notify at CosEvent_impl.cc:634
#7 0x00006418 in ProxyPullConsumer_impl::callback at CosEvent_impl.cc:
412
#8 0x015b8738 in MICO::IIOPProxy::exec_invoke_reply
#9 0x015b8e18 in MICO::IIOPProxy::handle_invoke_reply
#10 0x015b9974 in MICO::IIOPProxy::handle_input
#11 0x015ba0a0 in MICO::IIOPProxy::input_callback
#12 0x015b1b24 in MICO::GIOPConn::input_ready
#13 0x015b2f64 in MICO::GIOPConn::do_read
#14 0x01569608 in MICO::SelectDispatcher::handle_fevents
#15 0x0156ca8c in MICO::SelectDispatcher::run
#16 0x015b324c in MICO::GIOPConnReader::_run
#17 0x016f1998 in MICOMT::Thread::_thr_startup
#18 0x016f1b64 in MICOMT::Thread::ThreadWrapper
#19 0x9002b908 in _pthread_body


Thread B:
#0 0x9002bfc8 in semaphore_wait_signal_trap
#1 0x90001810 in pthread_mutex_lock
#2 0x00013394 in MICOMT::Mutex::lock at pthreads.h:172
#3 0x00013410 in MICOMT::AutoLock::AutoLock at os-thread.h:173
#4 0x0000851c in ProxyPullSupplier_impl::notify at CosEvent_impl.cc:332
#5 0x00008448 in ProxyPullSupplier_impl::pull at CosEvent_impl.cc:292
#6 0x0000445c in PullSupplier_skel2::invoke at CosEvent_impl.cc:178
#7 0x000067c8 in ProxyPullSupplier_impl::invoke at CosEvent_impl.cc:267
#8 0x0164004c in MICOPOA::POA_impl::perform_invoke
#9 0x0164195c in MICOPOA::POA_impl::local_invoke
#10 0x0164396c in MICOPOA::POA_impl::invoke
#11 0x0158d634 in CORBA::ORB::invoke_async
#12 0x015a5480 in MICO::IIOPServer::exec_invoke_request
#13 0x015bbdb0 in MICO::IIOPServer::handle_invoke_request
#14 0x015bcd94 in MICO::IIOPServer::handle_input
#15 0x015be370 in MICO::IIOPServer::input_callback
#16 0x015ae510 in MICO::InputHandler::process
#17 0x016f302c in MICO::PassiveOperation::_run
#18 0x016f7858 in MICO::WorkerThread::_run
#19 0x016f1998 in MICOMT::Thread::_thr_startup
#20 0x016f1b64 in MICOMT::Thread::ThreadWrapper
#21 0x9002b908 in _pthread_body


I applied the following patch to solve the problem:

Index: CosEvent_impl.cc
===================================================================
RCS file: /usr/src/cvs/Communication/CORBA/mico/coss/events/
CosEvent_impl.cc,v
retrieving revision 1.2
diff -u -r1.2 CosEvent_impl.cc
--- CosEvent_impl.cc 25 Jan 2009 13:52:04 -0000 1.2
+++ CosEvent_impl.cc 26 Jan 2009 01:53:37 -0000
@@ -191,10 +191,12 @@

//--------------------------------------------------------------------
----

-ProxyPullSupplier_impl::ProxyPullSupplier_impl (EventChannel_impl
*impl)
+ProxyPullSupplier_impl::ProxyPullSupplier_impl (EventChannel_impl
*impl) :
+ channel(impl),
+ connected(TRUE), // Todo: Why not FALSE? No supplier is
currently connected
+ requests(FALSE, MICOMT::Mutex::Recursive),
+ events(FALSE, MICOMT::Mutex::Recursive)
{
- channel = impl;
- connected = TRUE; // Todo: Why not FALSE? No supplier is
currently connected
}

void


Ciao

Thomas

--
Thomas Schmidt
Schneiderstr. 16
D-29575 Altenmedingen
Phone: [phone]
Cellular: [phone]
Skype: ThCSchmidt
Email: ***@vodafone.de
PGP: Key-ID: 0x810B6206