Experimental Physics and Industrial Control System
Hello:
We're having problems with IOCs deadlocking when re-loading the
Channel Access Security configuration files at runtime.
Maybe somebody else has seen this, too?
When doing this via the subroutine record AS routines,
a follow-up 'asDump' on the IOC shell will show that the file
was indeed loaded OK, but no more connections are allowed.
When instead running 'asInit' from the IOC shell, that hangs,
and a CTRL-C shows a stack trace that's analyzed below.
This happens with both R3.14.7 and R3.14.8.2,
on IOCs that do very different things.
After an IOC reboot, 'asInit' calls work fine,
and the access security files are of course OK as well.
By looking at the affected IOCs and their uptime, we assume
that this is caused by something that happened on the SNS
network between March 13 and April 4.
In the past, we suspected the 'pure Java CA client' code
to cause CA security related deadlocks. In principle,
we don't expect any more pure Java CA client code on the
SNS controls network, but we can't be 100% sure.
On the other hand, this deadlock could be completely unrelated
to Java CA, so forget all I said about Java CA.
Anyway, here's the stack trace with guesses based on
about 2 hours of comparing the stack offsets with the vxWorks 'l'
output and the 'gcc -S' PowerPC assembly code:
1e1a54 yystart +96c: asInit ()
1b5b1a8 asInit +10 : 1b5ab3c () = asInitCommon()
1b5ac28 asTrapWriteRegisterListener+384: asInitFile ()
1b59564 asInitFile +7c : asInitFP (34a7)
1b545dc asInitFP +11c: asInitialize ()
1b542b0 asInitialize +31c: 1b55ec0 ()
This is asAddMemberPvt()
1b56018 asDumpMemFP +49c: 1b561cc ()
This is asComputePvt()
1b563c8 asDumpMemFP +84c: 1b650dc ()
This must be the change-of-access-rights callback
at the end of asComputePvt():
if(pasgclient->pcallback && oldaccess!=access) {
(*pasgclient->pcallback)(pasgclient,asClientCOAR);
1b6519c casUserNameInitiatingCurrentThread+1ebc: 1b64f5c ()
Based on a grep of the sources, the only code that registers for such
a callback is in rsrv/camessage.c, so this must be
casAccessRightsCB(),
which calls epicsMutexMustLock(pclient->eventqLock)
1b6502c casUserNameInitiatingCurrentThread+1d4c: epicsMutexLock ()
1a7a7c0 epicsMutexLock +24 : semTake ()
1f0c74 semTake +13c: semMTake ()
Deadlock...
-Kay
- Replies:
- Re: channel access security deadlock from asInit() Ralph Lange
- Re: channel access security deadlock from asInit() Kay-Uwe Kasemir
- RE: channel access security deadlock from asInit() Jeff Hill
- Navigate by Date:
- Prev:
Re: edm: Displaying numeric information Tim Mooney
- Next:
Re: channel access security deadlock from asInit() Ralph Lange
- 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: edm: Displaying numeric information John Sinclair
- Next:
Re: channel access security deadlock from asInit() Ralph Lange
- 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