Experimental Physics and Industrial Control System
|
Hi Matt,
On Sep 10, 2021, at 10:05 AM, Matt Newville < newville at cars.uchicago.edu> wrote:
On Thu, Sep 9, 2021 at 7:08 PM Johnson, Andrew N.
wrote:
However I do think that the access fault you’re seeing is because a thread that is calling libca doesn’t have a CA context.
Does pyepics give access to the libca routines ca_current_context() and ca_attach_context() ? If so I would recommend having that watchdog thread
explicitly attach to the context that was created for the main thread. I think that will probably solve the problem if those APIs are available.
Yes, those are available. There is also a simple subclass of threading.Thread (epics.ca.CAThread) that explicitly attaches the thread to the initial CA context. My recollection
was that Mark tried this and it didn't help.
I would definitely recommend using your subclass then, even if it doesn’t fix this problem by itself.
The situation that I am concerned about is there being 2 copies of libca and libCom linked into the same process — that could lead to all kinds of problems when symbols are looked up dynamically if the second copy overrides calls to the first once it gets
loaded. This problem is being reported on Windows, and the behavior of dynamic loading there will probably be different than on Linux.
Is there any way to get a stack-trace from the C/C++ world when this dies? Mark’s traceback only showed the Python side, and it would be helpful to see where this is coming from in the underlying C/C++ libraries too:
File "C:\Users\rivers\Anaconda3\envs\tomoscan\lib\site-packages\epics\ca.py", line 923, in poll
pend_event(evt)
File "C:\Users\rivers\Anaconda3\envs\tomoscan\lib\site-packages\epics\ca.py", line 910, in pend_event
ret = libca.ca_pend_event(timeout)
OSError: exception: access violation reading 0x0000000000000048
The access violation there looks very much like an offset from a NULL pointer, but knowing what C++ routine is running at the time would be a lot more helpful. I might be wrong about this being the CA context, but we’ll probably need more information
to find out what’s actually happening.
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|
- Replies:
- Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Matt Newville via Tech-talk
- References:
- Incompatibility of pyepics and pvaPy 4.0.0 on Windows Mark Rivers via Tech-talk
- Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Veseli, Sinisa via Tech-talk
- Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Johnson, Andrew N. via Tech-talk
- RE: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Mark Rivers via Tech-talk
- Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Johnson, Andrew N. via Tech-talk
- Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Matt Newville via Tech-talk
- Navigate by Date:
- Prev:
Re: Cannot build StreamDevice on Windows 64bit Heinz Junkes via Tech-talk
- Next:
Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Matt Newville 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
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Matt Newville via Tech-talk
- Next:
Re: Incompatibility of pyepics and pvaPy 4.0.0 on Windows Matt Newville 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
2019
2020
<2021>
2022
2023
2024
|
ANJ, 10 Sep 2021 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|