RE: camonitor bug for string as array of chars

[Mark Rivers <rivers@cars.uchicago.edu>]

> Maybe camonitor should be \0-terminating the array that it gets from CA too,

Yes, I think it should.  It knows it's printing a string, and it knows how long the array actually is, since camonitor without -S prints the correct values.

> you should ensure there is a \0 terminating the char 
> array and include it in the element count that you give the waveform record.

Since that's not the way we've been doing it asynPortDriver, and since the only client that seems to have problems is camonitor -S, I am reluctant to do that.  It could break things, since now the element count will include the \0, while previously it did not.  Is it documented anywhere that a waveform record containing a string should include the \0, and include it in the element count?

Thanks,
Mark


-----Original Message-----
From: Andrew Johnson [mailto:anj@aps.anl.gov] 
Sent: Monday, September 10, 2012 5:35 PM
To: Mark Rivers
Cc: 'Ralph Lange'; EPICS Tech Talk
Subject: Re: camonitor bug for string as array of chars

Hi Mark,

On 2012-09-10 Mark Rivers wrote:
> 
> I don't include the \0 when I update the waveform record, I tell it that
>  the length of the data in the callback to the waveform records is
>  strlen(data).  This is asyn's interrupt callback on the asynOctet
>  interface.

I think that may be why; you should ensure there is a \0 terminating the char 
array and include it in the element count that you give the waveform record.  
Maybe camonitor should be \0-terminating the array that it gets from CA too, 
but remember that this transport of strings is piggy-backing on the normal 
array behavior that CA implements; CA doesn't know what the array data 
represents so it can't go adding extra terminating zero bytes itself.  Note 
that for the other long string field types a \0 terminator is included in the 
data transported.

> Note that medm and caget both work correctly, as does camonitor without -S.
>  Only camonitor -S has the problem. It is acting as if it is ignoring the
>  current length of the array.  I am not sure if the CA monitor includes the
>  current length of the array, or if that can only be obtained when
>  camonitor first connects to the PV?  But if that is true, why does medm
>  work correctly?

If a client passes a zero array length parameter when subscribing to a 
waveform record it will be given exactly NORD bytes with each monitor (and 
told the new length each time).  MEDM keeps the count of the number of 
elements in the data it gets from CA and may not be relying on that \0 
terminator when it updates its text widgets.  I suspect camonitor is just 
calling printf(), which assumes there's a zero terminator.

> -----Original Message-----
> From: Ralph Lange [mailto:Ralph.Lange@gmx.de]
> Sent: Monday, September 10, 2012 4:28 PM
> To: Mark Rivers
> Cc: Andrew Johnson; EPICS Tech Talk
> Subject: Re: camonitor bug for string as array of chars
> 
> Hi Mark,
> 
> A quick check on Linux (3.14.12.2 w/o additional patches, using caput -S
> to change a softIOC wf record) shows slightly different behavior,
> 
> leaving a better impression:
> > ./projects/epics/base/3.14/3-14-12-2/bin/linux-x86_64/camonitor
> 
> iocImageFilePath
> iocImageFilePath 2012-09-10 22:44:40.415229 17 48 49 50 51 52 53 54 55
> 56 57 97 98 99 97 98 99 0
> iocImageFilePath 2012-09-10 22:45:10.335328 16 48 49 50 51 52 53 54 55
> 56 57 97 98 99 97 98 0
> iocImageFilePath 2012-09-10 22:45:13.694734 15 48 49 50 51 52 53 54 55
> 56 57 97 98 99 97 0
> iocImageFilePath 2012-09-10 22:45:17.030678 14 48 49 50 51 52 53 54 55
> 56 57 97 98 99 0
> 
> > ./projects/epics/base/3.14/3-14-12-2/bin/linux-x86_64/camonitor -S
> 
> iocImageFilePath
> iocImageFilePath 2012-09-10 23:08:31.703178 0123456789abcabc
> iocImageFilePath 2012-09-10 23:08:36.974504 0123456789abcab
> iocImageFilePath 2012-09-10 23:08:39.830474 0123456789abca
> iocImageFilePath 2012-09-10 23:08:43.006382 0123456789abc
> 
> Note that the trailing \0 is part of the array in my case, but not in
>  yours. Assuming reused buffers in the client, that would explain the
>  additional characters (old buffer contents) when printed as %s.
> 
> How do you update your waveform record? Do you include the \0?
> 
> @Andrew: How is "string as array of char" supposed to be used? Is the
> trailing \0 being part of the array the correct way?
> 
> Thanks,
> ~Ralph
> 
> On 03.09.2012 22:45, Mark Rivers wrote:
> > Hi Ralph,
> >
> > On a closely related topic, there appears to be a bug in "camonitor -S"
> > in 3.14.12.2.
> >
> > I have a waveform record that contains a file path and name. If I make
> > the string one character shorter each time the record processes then
> > "caget -S" works fine:
> >
> > The following is the output when I shorten the base file name from
> > "abcdef", to "abcde" to "abcd" to "abc".
> >
> > corvette:~/devel/quadEM/documentation>caget -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > /home/epics/scratch/abcdef_643.nc
> > corvette:~/devel/quadEM/documentation>caget -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > /home/epics/scratch/abcde_644.nc
> > corvette:~/devel/quadEM/documentation>caget -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > /home/epics/scratch/abcd_645.nc
> > corvette:~/devel/quadEM/documentation>caget -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > /home/epics/scratch/abc_646.nc
> >
> > camonitor also works fine if I read it as a byte array:
> >
> > corvette:~/devel/quadEM/documentation>camonitor
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > 2012-09-03 15:38:44.323680 33 47 104 111 109 101 47 101 112 105 99 115 47
> > 115 99 114 97 116 99 104 47 97 98 99 100 101 102 95 54 52 55 46 110 99
> > 13SIM1:netCDF1:FullFileName_RBV 2012-09-03 15:38:51.749183 32 47 104 111
> > 109 101 47 101 112 105 99 115 47 115 99 114 97 116 99 104 47 97 98 99 100
> > 101 95 54 52 56 46 110 99 13SIM1:netCDF1:FullFileName_RBV 2012-09-03
> > 15:38:57.862994 31 47 104 111 109 101 47 101 112 105 99 115 47 115 99 114
> > 97 116 99 104 47 97 98 99 100 95 54 52 57 46 110 99
> > 13SIM1:netCDF1:FullFileName_RBV 2012-09-03 15:39:01.644249 30 47 104 111
> > 109 101 47 101 112 105 99 115 47 115 99 114 97 116 99 104 47 97 98 99 95
> > 54 53 48 46 110 99
> >
> > However, if I do camonitor -S it does not work correctly:
> >
> > corvette:~/devel/quadEM/documentation>camonitor -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > 2012-09-03 15:40:04.275117 /home/epics/scratch/abcdef_651.nc
> > 13SIM1:netCDF1:FullFileName_RBV 2012-09-03 15:40:10.385085
> > /home/epics/scratch/abcde_652.ncc 13SIM1:netCDF1:FullFileName_RBV
> > 2012-09-03 15:40:17.546130 /home/epics/scratch/abc_653.ncncc
> >
> > Note that it is showing extra characters at the end of the string.
> >
> > However, if I exit camonitor and run it again with the last string
> > unchanged it displays that string correctly:
> >
> > corvette:~/devel/quadEM/documentation>camonitor -S
> > 13SIM1:netCDF1:FullFileName_RBV 13SIM1:netCDF1:FullFileName_RBV
> > 2012-09-03 15:40:17.546130 /home/epics/scratch/abc_653.nc
> >
> > medm correctly displays the string as it gets shortened.
> >
> > Mark
> 


- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte