Re: "epicsMutex pthread_mutex_unlock failed" with pyepics/pcaspy

[Jameson Graef Rollins <jrollins@ligo.caltech.edu>]

On Wed, May 13 2015, Michael Davidsaver <mdavidsaver@bnl.gov> wrote:
> On 05/13/2015 01:06 PM, Jameson Graef Rollins wrote:
>> On Tue, May 12 2015, Michael Davidsaver <mdavidsaver@bnl.gov> wrote:
>>> ...
>> Hi, Michael.  I should have mentioned that I did try doing this at your
>> suggestion, but wasn't able to devine anything useful myself.  I'm not
>> quite sure what I'm looking for, though:
>
> The error is coming from:
>
> http://bazaar.launchpad.net/~epics-core/epics-base/3.14/view/head:/src/libCom/osi/os/posix/osdMutex.c#L108
>
> If the unlock fails then cantProceed() is called, which calls
> epicsThreadSuspendSelf.  The posix version of which ultimately calls
> pthread_cond_wait().
>
> http://bazaar.launchpad.net/~epics-core/epics-base/3.14/view/head:/src/libCom/osi/os/posix/osdEvent.c#L75

Thanks Michael!  This sounds somewhat promising.

> From the top two frames this could be either thread #1 or #4.  Can you
> post the full stacks?

This program utilizes two processes: a "main" daemon process and a
"worker" sub-process.  The daemon holds the PCAS, while the worker uses
pyepics to do the work.

Attached is the gdb bt output for the threads of both the "MAIN" and the
"WORKER" for one of these wedged nodes.  Like I said, I'm pretty sure
the problem is in the PCAS, so I think the problem is in the MAIN, but I
include the WORKER bt for completeness.

I don't actually have a wedged node right now, so I can't get any more
info until it happens again.  If there's some other gdb info I can
retrieve next time this happens, please do let me know.

jamie.

Attachment: epicsMutex_pthread_error-SEI_HAM6
Description: Binary data

Attachment: signature.asc
Description: PGP signature