EPICS Base

Bug #672665
Comment #8

Comment 8 for bug 672665

Revision history for this message

Jeff Hill (johill-lanl) wrote on 2010-11-15:

Only this thread is blocked on a lock which is a contra-indicator for a deadlock; instead this could be a compromised lock or alternatively see below. A lock gets compromised if it isn't unlocked when traversing an unusual code path such as a c++ exception. Its less likely for that scenario to occur in this code because it uses an automatic instance of a Guard class to manage locking an unlocking, but see below for another possibility.

Thread 3 (Thread 0xa9e72b90 (LWP 2860)):
#0 0x0084e422 in __kernel_vsyscall ()
#1 0x00a470b9 in __lll_lock_wait () from /lib/libpthread.so.0
#2 0x00a42864 in _L_lock_824 () from /lib/libpthread.so.0
#3 0x00a4271d in pthread_mutex_lock () from /lib/libpthread.so.0
#4 0x009a3ca6 in pthread_mutex_lock () from /lib/libc.so.6
#5 0x06119746 in epicsMutexOsdLock (pmutex=0x9179320) at ../../../src/libCom/osi/os/posix/osdMutex.c:44
#6 0x06111700 in epicsMutexLock (pmutexNode=0x9179340) at ../../../src/libCom/osi/epicsMutex.cpp:145
#7 0x06111e1f in epicsMutex::lock (this=0x91792a4) at ../../../src/libCom/osi/epicsMutex.cpp:238
#8 0x051a2f9c in tcpRecvThread::run (this=0x9333524) at ../../../include/epicsGuard.h:71
#9 0x0611150a in epicsThreadCallEntryPoint (pPvt=0x9333528) at ../../../src/libCom/osi/epicsThread.cpp:85
#10 0x0611860b in start_routine (arg=0x92f3678) at ../../../src/libCom/osi/os/posix/osdThread.c:282
#11 0x00a4049b in start_thread () from /lib/libpthread.so.0
#12 0x0099742e in clone () from /lib/libc.so.6

A lock might be taken at any of lines 443, 482, 504, 600, 593, 547, and 585 in tcpiiu.cpp; all of which take the per circuit lock.

Looking closer I see also at line 502 we have"callbackManager mgr ( this->ctxNotify, this->cbMutex );". This is taking the callback manager lock which is the traffic cop which, in non-preemptive callback mode, prevents a callback from proceeding unless the application is executing in the library.

Is this application running in non-preemptive or preemptive callback mode? If so, does it call ca_poll periodically to allow ca client library background activity to proceed?

Only this thread is blocked on a lock which is a contra-indicator for a deadlock; instead this could be a compromised lock  or alternatively see below. A lock gets compromised if it isn't unlocked when traversing an unusual code path such as a c++ exception. Its less likely for that scenario to occur in this code because it uses an automatic instance of a Guard class to manage locking an unlocking, but see below for another possibility.

A lock might be taken at any of lines 443, 482, 504, 600, 593, 547, and 585 in tcpiiu.cpp; all of which take the per circuit lock.

Is this application running in non-preemptive or preemptive callback mode? If so, does it call ca_poll periodically to allow ca client library background activity to proceed?