You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating an array PV with 'count' : 6, one can later call setParam with 0, 1, 2, .. 6 elements.
Reasonably recent Channel Access clients support such changing array sizes.
Turns out that pcaspy even allows calling setParam with more elements than originally specified by count, and some CA clients handle it, but the CA gateway does not.
Our PV Gateway Version 2.1.0 built with EPICS R3.14.12.6 crashed with symptoms of memory corruption each time we accessed such a PV that declared 'count': 1000 but then set the value to an array with 100000 elements. The last log message before each crash mentioned a value update with 100000 elements, but erroneously associated it with a different channel, again as a result of memory corruption.
While this is in part a bug in the gateway, the common agreement for the use of variable size arrays is that the 'count', which is for record-based IOCs configured via the waveform NELM field, sets the maximum array size, and value updates will then contain 0, 1, 2, .. elements up to that maximum element count. This allows clients to reserve a known amount of memory for storing received value updates.
Can pcaspy check the data passed to setParam, and in case of arrays at least warn, maybe even truncate or ignore array values with more than count elements?
The text was updated successfully, but these errors were encountered:
I did not react on this issue because it is a good "feature" to provide variable length array PV. It is upon the application developer to respect the array size limit.
Well, yes, it's these days common to have 'array' classes that can simply change size, internally freeing/re-allocating memory as necessary.
For control system devices, however, it's often better to reserve the maximum required array memory once and then keep using that same memory to prevent memory fragmentation or delays from re-allocations. So the array size may change, but must stay within an upper limit.
In other words: "It is upon the application developer to configure the array size limit.", and pcaspy should then stay within that limit.
When creating an array PV with
'count' : 6
, one can later callsetParam
with 0, 1, 2, .. 6 elements.Reasonably recent Channel Access clients support such changing array sizes.
Turns out that pcaspy even allows calling
setParam
with more elements than originally specified bycount
, and some CA clients handle it, but the CA gateway does not.Our PV Gateway Version 2.1.0 built with EPICS R3.14.12.6 crashed with symptoms of memory corruption each time we accessed such a PV that declared
'count': 1000
but then set the value to an array with 100000 elements. The last log message before each crash mentioned a value update with 100000 elements, but erroneously associated it with a different channel, again as a result of memory corruption.While this is in part a bug in the gateway, the common agreement for the use of variable size arrays is that the 'count', which is for record-based IOCs configured via the waveform NELM field, sets the maximum array size, and value updates will then contain 0, 1, 2, .. elements up to that maximum element count. This allows clients to reserve a known amount of memory for storing received value updates.
Can pcaspy check the data passed to
setParam
, and in case of arrays at least warn, maybe even truncate or ignore array values with more thancount
elements?The text was updated successfully, but these errors were encountered: