Ouch!
Thanks for your reply. I was hoping for the relieving news that I was
only being stupid ... now look at this.
Your impression of statistical misfunction (especially more errors on
supposedly faster systems) leads to the .... huagh! .... thought that
this might be connected to timing issues or race conditions between the
CA server and the Access Security system.
Jeff - do you recall a Channel Access change between 3.14.8.2 and 3.14.9
that you can relate?
Regards,
Ralph
ps. There were also some parser cleanup things done to the asLib for
3.14.9, but these don't look dangerous, either. I will try to just use
the as subdirectory from 3.14.8.2 to rule out that possibility.
Steven Hartman wrote:
On Wed, 8 Aug 2007, Ralph Lange wrote:
Does anyone have similar experiences?
Yes! I have just been investigating the same problem, though my symptoms
are slightly different then yours (and even more strange).
The problem seems to be restricted to 3.14.9 IOCs (do not see it with
3.14.8.2 or 3.13.10). I have observed it with both VxWorks (5.5.1 on
MVME5110-2261 with WRS compilers) and Linux (2.6 kernel, x86) IOCs.
The stranger part is the client access side (using Linux and Solaris
clients). Some 3.14.9 clients always work as expected (medm, camonitor,
alh, adt, burt). Other 3.14.9 clients (same host, same user) sometimes
work but usually get a no read access error (caget, StripTool, probe). I
am not seeing any unexpected no write access errors. Caput often shows a
no read access error (from the caget() function) but then a successful
write. All 3.13.10 (Solaris) clients appear to work as expected. I have
not seen any read access errors over channel access from IOC to IOC.
Some additional observations: Linux 3.14.9 caget seems to have a much
higher unexpected no-read access error rate (>90%) then Solaris 3.14.9
caget (<40%). Passing 2 PVs to caget (one PV on 3.14.9 IOC one on 3.13.10
IOC) always results in a successful read of both PVs.
Not enabling access security on the IOC makes the problem go away. But the
problem appears with an access_security.acf file which is used
successfully for IOCs at other EPICS versions. Even a minimal
access_security.acf file (default read and write access for anyone) shows
this problem. I have not seen any problem of access security not denying
when it should. Access security dump routines are consistent with the
input file and consistent with IOCs at < 3.13.10. I am not using any calc
expressions in this access_security.acf file.
There were changes in the calc expression parser between 3.14.8.2 and
3.14.9 which impacted asLib,
(http://www.aps.anl.gov/epics/base/R3-14/9-docs/RELEASE_NOTES.html), but
given the strange client side behavior, I suspect that this is not where
the problem lies.
- Replies:
- Re: Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
- References:
- Possible Bug in 3.14.9 Access Security on mv2100 Ralph Lange
- Re: Possible Bug in 3.14.9 Access Security on mv2100 Steven Hartman
- Navigate by Date:
- Prev:
Re: Possible Bug in 3.14.9 Access Security on mv2100 Steven Hartman
- Next:
Re: Possible Bug in 3.14.9 Access Security on mv2100 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: Possible Bug in 3.14.9 Access Security on mv2100 Steven Hartman
- Next:
Re: Possible Bug in 3.14.9 Access Security on mv2100 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
|