Experimental Physics and
Industrial Control System

Wang Xiaoqiang <[email protected]> · Wed, 7 Dec 2016 12:08:21 +0100

Hi Bruce,

Thanks. The crash cannot be reproduced with this fix.

Since the casPVI lock is now acquire during channel creation,

just a purely theoretical thinking, is there a chance that the deadlock

would happen if a new CA client wants to connect while PCAS application

is calling postEvent?

I am running the same test again, and in addition four loops to make

continuous caget requests.

$ while [ 1 ]; do caget MTEST:MinValue; done;

Best
Xiaoqiang

On 12/07/2016 10:45 AM, Bruce Hill wrote:

Hi Xiaoqiang,
Thanks, I was able to reproduce the bug using your suggestions.
I've submitted a proposed fix on launchpad.   Please let me know if you
have a chance to try it.    My version ran all day today w/o crashing.
https://code.launchpad.net/~bhill/epics-base/pcas-deadlock-fix-3.14/+merge/312638
<https://code.launchpad.net/%7Ebhill/epics-base/pcas-deadlock-fix-3.14/+merge/312638>

Cheers,
- Bruce

On 12/6/2016 1:38 AM, Wang Xiaoqiang (PSI) wrote:

Hi Bruce,

I replied you here
https://github.com/paulscherrerinstitute/pcaspy/issues/29#issuecomment-265103000

I carried out the described test procedure on a SL6 64bit Linux PC.
The problem appears definitely in a few seconds.

Best
Xiaoqiang

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Bruce Hill
Sent: Dienstag, 6. Dezember 2016 04:15
To: [email protected]
Subject: Re: deadlock in pcas 3.14.12.6-rc1

Hi Xiaoqiang,
Do you have a pcaspy example that I can run to reproduce this?

I'm running pcaspy 0.6.2 currently, but could also build from a github
branch if available.

Thanks,
- Bruce

On 11/10/2016 08:59 AM, Wang Xiaoqiang (PSI) wrote:

Hi,

I am testing the support of dynamic array in the recent base
3.14.12.6-rc1.
Using a normal pcaspy application, which updates ~15 Hz. It
repeatedly gets into a deadlock state.

The analysis has been put up here
https://github.com/paulscherrerinstitute/pcaspy/issues/29

The solution could be reversing the lock order during
casEventSys::process. But it does not seem to be easy, because the
chain of calls involved.

Best
Xiaoqiang

--
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System