Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 3 Sep 2012 20:45:06 +0000

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System