Re: Possible Bug in 3.14.9 Access Security on mv2100

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Ralph,

that's probably not the only CA problem in 3.14.9.
In May, I repored a bug to the Mantis bugtracker which has not even been 
assigned until now. (Maybe posting it to tech-talk helps.)

> Summary 
> long integer values are corruped in R3.14.9
>
> Description
> When writing integer values with a CA client (e.g. medm) to a long integer channel (e.g. longout record), the upper bytes get corrupted. The lower 2 bytes are OK.
> I can't see the error when the client is caput from base.
> Client and IOC run on a linux-x86 machine.
> The problem is new in 3.14.9.

It seems some things in CA have been changed in 3.14.9 and not to the 
best. I just don't use 3.14.9.

Dirk

Ralph Lange wrote:
> More observations from me:
>
> I can also see the faulty behaviour against a Linux 3.14.9 IOC. 
> Including the statistical behaviour that Steven was reporting. Some of 
> the caget calls get the unexpected "no read", others don't. On the same 
> Linux host, caget fails about 20%. Cross to vxWorks mv2100 IOC, caget 
> fails 100%. Camonitor works all the time, against all type IOCs.
>
> Rebuilding Base 3.14.9 with the as subdirectory from 3.14.8.2 does not 
> change the faulty behaviour at all. The as parser cleanup things got away.
>
>
> More observations from Steven:
>
> I already have optimization turned off for the cross compiler (have been 
> bit by that on VxWorks before) but have host optimization on. I tried 
> turning off host optimization and recompiling caget on linux, but the 
> problem remained.
>
> Now, I just rebuilt all of base on linux with HOST_OPT=NO. Even stranger.
> Using optimized build on linux, caget failed with an unexpected read 
> access error 19 out of 20 times just tested. Using non-optimized build 
> on linux, caget failed 2 out of 20 times!
>
>
> Houston, we have a problem.
>
> Ralph

--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182