EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: libca bug?
From: Matt Newville via Tech-talk <[email protected]>
To: Bruno Martins <[email protected]>
Cc: tech-talk <[email protected]>
Date: Fri, 3 May 2019 15:58:44 -0500
Hi Bruno, 


On Fri, May 3, 2019 at 2:44 PM Bruno Martins via Tech-talk <[email protected]> wrote:
Hi all,

This is a bug (or is it?) that involves libca, pyDevSup and pyepics. We use pyDevSup on some of our IOCs. On most of them, we also want to use pyepics.

Everything works fine until we issue exit() on the IOC shell. When that happens, the IOC segfaults.

I believe that the following are true:

  -  pyepics dynamically loads libca, which ends up being the same instance as the one loaded by the IOC itself (for dbCa)
  -  pyepics does not share the same context with dbCa if it is run on its own thread and the proper context_create call is performed
  -  Even when not sharing libca contexts, the variable caClientCallbackThreadId ends up being the same for pyepics and dbCa.
  -  cacExitHandler runs when the IOC is exiting and sets caClientCallbackThreadId=0 [1]
  -  Any subsequent libca call by pyepics (during its cleanup) that tries to use caClientCallbackThreadId will segfault.

Possible solutions:

  -  Register pyepics' finalize_libca with pyDevSup's addHook('AtIocExit',...), but this runs after dbCa cleanup. Can it be made to run before? Can there be a 'BeforeIocExit' hook?
  -  Remove caClientCallbackThreadId=0 in libca. I have no idea about the implications.
  -  Something else?

Of course, I understand that both the IOC itself and pyepics kind of expect to be the sole users of libca in their processes. This assumption doesn't hold when I have pyepics inside a IOC.



 There definitely will be challenges when trying to use pyepics from within an IOC or embedded in an application that also uses CA.  

The assumption that pyepics makes (or "among the assumptions that pyepics makes") is that the process it is running in has not loaded libca/libCom and that pyepics needs to do this.  I think it has to be able to connect to the dynamic lib within its own namespace -- I do not know of a way to ask "what dynamic libs are already loaded" from python -- so I sort of doubt that could change.  I also think you will absolutely need to specify which libCA to use by setting PYEPICS_LIBCA before initially the epics.ca python module.  It sounds like you are doing this, but I doubt that it would work otherwise.

Currently, pyepics always calls ca_create_context().  For the "normal" case (not embedded in a process already using CA), that makes sense. We could make that optional, but I'm not sure if  "attach_context()" would actually work to find a context created within the main IOC process but not within the embedded python process.   That might be worth trying.

Are you using Python threads within the embedded Python process?  That could cause a complication -- for "normal" usage, it tries to maintain all CA connections in the initial context.  

There is a flag `ca.AUTO_CLEANUP` that could be set to False to prevent 'ca.finalize_libca()` from being called when exiting the App.   I sort of doubt that would actually help, but it's easy enough to try.  I have no idea what order of the clean-up steps are done in, or what would happen to connections made to other IOCs.  Anyway, the steps of `ca.finalize_libca()` might be broken up into finer-grain steps.
 
--Matt Newville


Replies:
Re: libca bug? Michael Davidsaver via Tech-talk
References:
libca bug? Bruno Martins via Tech-talk

Navigate by Date:
Prev: Re: libca bug? Michael Davidsaver via Tech-talk
Next: Re: libca bug? Johnson, Andrew N. via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: libca bug? Matt Newville via Tech-talk
Next: Re: libca bug? Michael Davidsaver via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  2021  2022  2023  2024 
ANJ, 03 May 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·