EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA get of zero length array
From: Michael Davidsaver <[email protected]>
To: EPICS core-talk <[email protected]>
Date: Tue, 17 Apr 2018 22:19:27 -0700
I remembered that there is an issue open for this

https://bugs.launchpad.net/epics-base/+bug/1242919

On 04/17/2018 11:40 AM, Michael Davidsaver wrote:
> On 04/17/2018 06:18 AM, Jörn Dreyer wrote:
>> ~ $caget -d 2 HIBEF:XFEL:image1:ArrayData | more
>> HIBEF:XFEL:image1:ArrayData
>>     Native data type: DBF_FLOAT
>>     Request type:     DBR_FLOAT
>>     Element count:    1000
>>     Value:            2.02038e-39 0 ...
> 
> Don't ask me why, but I was annoyed at seeing (again) this garbage element
> in what should be a zero'd array.  So I traced it back.  The issue is in
> camessage.c in read_reply().  Specifically, that
> 
>> dbr_size_n(X,0) == dbr_size_n(X,1)
> 
> as the underlying dbr_size[] includes the size of meta-data and one value element.
> 
> So dbChannel_get_count() correctly sets item_count to zero.  Then read_reply()
> zeros part, but all, of the buffer.  In this case data_size includes the first
> value element, which isn't set by dbChannel_get_count(), and not isn't zeroed
> here.
> 
>> ca_uint32_t data_size = dbr_size_n(pevext->msg.m_dataType, item_count);
>> ...
>> memset((char *) pPayload + data_size, 0, payload_size - data_size);
> 
> This is only in the !autosize case (get or non-dynamic monitor).
> 
> I'm not sure where to fix this, as there would seem to be several possibilities,
> depending on whether or not dbr_size_n() should change.
> 


References:
CA get of zero length array Michael Davidsaver

Navigate by Date:
Prev: Re: obscure EPICS+RTEMS makefile problem Michael Davidsaver
Next: Re: obscure EPICS+RTEMS makefile problem Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: CA get of zero length array Michael Davidsaver
Next: obscure EPICS+RTEMS makefile problem Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
ANJ, 18 Apr 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·