On 5/3/19 12:43 PM, Bruno Martins via Tech-talk 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.
Do you have a stack trace?
Also, try setting the 'atExitDebug' iocsh variable before exit.
This prints the names of exit handlers as they run, which
might give some insight if the ordering isn't as expected.
> var atExitDebug 1
> 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?
Unfortunately no. Though this does suggest a rethink of addHook(),
and maybe also epicsAtExit() to be able to better express ordering
requirements.
> - 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.
The IOC isn't making such an assumption. eg. the sequencer creates its own CA context.
>
> [1] https://github.com/epics-base/epics-base/blob/3.15/src/ca/client/ca_client_context.cpp#L51
>
>
>
> Thanks!
>
> Bruno
- Replies:
- Re: libca bug? Johnson, Andrew N. via Tech-talk
- References:
- libca bug? Bruno Martins via Tech-talk
- Navigate by Date:
- Prev:
libca bug? Bruno Martins via Tech-talk
- Next:
Re: libca bug? 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:
libca bug? Bruno Martins 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
<2019>
2020
2021
2022
2023
2024
|