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
________________________________________
From: [email protected] [[email protected]] on behalf of Ralph Lange [[email protected]]
Sent: Monday, September 03, 2012 3:05 PM
To: J. Lewis Muir
Cc: EPICS Tech Talk
Subject: Re: caput off-by-one bug for string as array of chars
Hi Lewis,
thanks for reporting this!
Looking at the code, I can confirm the off-by-one bug you found in case
of the '-S' option (string as array of chars).
The fix you supplied looks fine, and I added it to the 3.14 branch.
However, I am not able to reproduce the bug using your database and
command file on my Linux machine (10,000s of iterations without a problem).
I found your shell script containing '\r' characters, so I am assuming
you see this behavior on Windows. Correct? Cygwin, native, or an
adventurous mix?
Note that inside caput, string arguments are pushed through
epicsStrnRawFromEscaped(), which understands and translates backslash
escape sequences. If your setup somehow changes forward slashes in
arguments to Windows-style backslashes, the current code in
epicsStrnRawFromEscaped() would regard a backslash being the last
character as illegal, and not copy it to the target string.
Can you try with your string value not ending in a slash? Do you still
see the error?
Far fetched, I know, but something like that might explain why the bug
does not show up on Linux.
Well ... in any case I can't tell you why the '-t' option should change
the behavior. Really weird.
Thanks again,
~Ralph
On 17.08.2012 01:12, J. Lewis Muir wrote:
> I believe there is an off-by-one bug in caput for the case of
> writing a string as an array of chars (i.e. the '-S' option) in
> EPICS Base 3.14.12.2. (Looking at the 3.15 source code, the bug
> is probably there as well, but I haven't tested it.)
>
> The caput program will sometimes write an incorrect value--a
> value different from the value passed as an argument. I believe
> this is because caput does not allocate enough memory to hold
> the string value *plus* the terminating null character.
>
> Attached is caput-string-off-by-one-fix.diff, a patch against
> EPICS Base 3.14.12.2 plus Known Problems patches, to fix the
> problem.
>
> Attached is image-file-path.db and reproduce-bug.sh which can be
> used to reproduce the problem.
>
> Load image-file-path.db into a soft IOC like this:
>
> dbLoadRecords("image-file-path.db","P=ioc23:")
>
> Run the reproduce-bug.sh program like this:
>
> $ sh reproduce-bug.sh
>
> On my system, it usually fails within 20 iterations. For example:
>
> $ sh reproduce-bug.sh
> [3] "/tmp/lys_001.img/" != "/tmp/lys_001.img"
>
> What I don't understand, though, is that if I add the '-t'
> option to the caput command in reproduce-bug.sh, the problem
> does not occur. I'd be interested to hear an explanation of why
> that is.
>
> Thanks,
>
> Lewis
- Replies:
- Re: camonitor bug for string as array of chars Ralph Lange
- 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
- Navigate by Date:
- Prev:
Re: caput off-by-one bug for string as array of chars Ralph Lange
- Next:
Re: caput off-by-one bug for string as array of chars 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: caput off-by-one bug for string as array of chars Ralph Lange
- Next:
Re: camonitor bug for string as array of chars Ralph Lange
- 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
|