Experimental Physics and
Industrial Control System

On Sep 9, 2021, at 5:16 PM, Mark Rivers <rivers at cars.uchicago.edu> wrote:

Ø  That could mean that calling pyepics code from inside a pvaccess callback/notification routine might no longer work if pyepics doesn’t properly set its CA context before calling routines inside libca (unfortunately that’s probably what’s happening, given the access violation that Mark is seeing).

 

The pyepics call that it crashing is not happening inside a pvaccess callback/notification routine, it is happening in the following code:

 

class TomoScan():

…

    def __init__(self, pv_files, macros):

…

        # Start the watchdog timer thread

        thread = threading.Thread(target=self.reset_watchdog, args=(), daemon=True)

        thread.start()

…

    def reset_watchdog(self):

        """Sets the watchdog timer to 5 every 3 seconds"""

        while True:

            self.epics_pvs['Watchdog'].put(5)

            time.sleep(3)

 

So the tomoscan constructor is creating a new thread with threading.Thread.  That thread is running the simple reset_watchdog function, which simply does an epics.PV.put(5) every 3 seconds.  That call crashes with pvaccess 4.0.0 under the following conditions:

-          tomoscan is built with the functions that include pvaccess

or

-          tomoscan is built without pvaccess but PYEPICS_LIBCA is pointing to the version of ca.dll that comes with pvaccess

 

From: Johnson, Andrew N. <anj at anl.gov> 
Sent: Thursday, September 9, 2021 5:06 PM
To: Veseli, Sinisa <sveseli at anl.gov>
Cc: Mark Rivers <rivers at cars.uchicago.edu>; EPICS tech-talk <tech-talk at aps.anl.gov>; De Carlo, Francesco <decarlo at anl.gov>; Nikitin, Viktor <vnikitin at anl.gov>
Subject: Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows

 

On Sep 9, 2021, at 2:38 PM, Veseli, Sinisa via Tech-talk <tech-talk at aps.anl.gov> wrote:

 

pvapy 4.0.0 uses epics base 7.0.6, while 3.1.0 used 7.0.4.1. However, there were some changes in pvapy 4.0.0 related to support for asynchronous gets that might be causing this.

 

There were also changes to the caProvider inside pvAccess made between Base 7.0.4.1 and 7.0.5 that made it more strict about saving and restoring the CA context pointer for the current thread, and changed the thread which is used to perform notifications to the PVA client code. That could mean that calling pyepics code from inside a pvaccess callback/notification routine might no longer work if pyepics doesn’t properly set its CA context before calling routines inside libca (unfortunately that’s probably what’s happening, given the access violation that Mark is seeing).

 

Calling pvaccess routines from inside a pyepics callback should be safe because now the provider routines first save the thread’s current context, set their own context, call libca, and then restore the previous context before returning. However notifications from pvAccess may now be made by a thread that has no attached CA context, and if a libca routine gets called in that context it might trigger this kind of problem.

 

- Andrew

 

-- 

Complexity comes for free, simplicity you have to work for.