Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Wed, 13 May 2015 17:25:04 -0400

On 05/13/2015 05:03 PM, Jameson Graef Rollins wrote:
> ...
> I think this is just a symlink issue.

Ok

> ...  I do however see a
> "_cas.so" that's included with the pcaspy package [1].

This is the one I meant.  This all looks normal.

So I'm 0 for 3 so far :)

>>> Thread 1 (Thread 0x7f8658d49700 (LWP 26265)):
...
>>> #4  0x00007f86529e2d05 in cantProceed (msg=<optimized out>) at ../../../src/libCom/misc/cantProceed.c:69
>>> #5  0x00007f8652568525 in casPVI::getExtServer() const () from /ligo/apps/ubuntu12/epics-3.14.12.2_long/base/lib/linux-x86_64/libcas.so.3.14
>>> #6  0x00007f8652c2efa3 in PV::postEvent (this=0x30a0200, value=...) at pcaspy/pv.cpp:83
>>> #7  0x00007f8652c1fdc9 in _wrap_PV_postEvent (args=<optimized out>) at pcaspy/casdef_wrap.cpp:9193
>>> #8  0x0000000000571b58 in PyEval_EvalFrameEx ()
> 
> Ok!  So what's to be done here?  Is this a problem in the pcaspy SWIG
> bindings, or in libcas?  I can't see anything obvious that is being
> called incorrectly:

In my experience, when pthread_mutex_unlock fails w/ EINVAL it is either
a sign of memory corruption, or that the lock has already been free'd
(w/ pthread_mutex_destory).

Given that the process doesn't crash I'm guessing its the later.

Is your application creating, or more importantly destroying, casPVI
instances when this error appears?  A race during destruction would
probably explain things.

Michael

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System