Hi Ralph,
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.
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?
Mark
-----Original Message-----
From: Ralph Lange [mailto:[email protected]]
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
>
- Replies:
- Re: camonitor bug for string as array of chars Andrew Johnson
- References:
- caput off-by-one bug for string as array of chars J. Lewis Muir
- Re: caput off-by-one bug for string as array of chars Ralph Lange
- RE: caput off-by-one bug for string as array of chars Mark Rivers
- Re: camonitor bug for string as array of chars Ralph Lange
- Navigate by Date:
- Prev:
Re: camonitor bug for string as array of chars Ralph Lange
- Next:
Re: How to profile an EPICS application on Linux J. Lewis Muir
- 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: camonitor bug for string as array of chars Ralph Lange
- Next:
Re: camonitor bug for string as array of chars Andrew Johnson
- 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
|