Experimental Physics and Industrial Control System
On 9/3/12 3:05 PM, Ralph Lange wrote:
> Hi Lewis,
>
> thanks for reporting this!
Hi, Ralph.
You're welcome!
> 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.
Thanks for looking into the problem and committing a fix!
> 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?
Mac OS X. Sorry to have not stated that; I assumed the problem
would occur on all platforms, but obviously that is not true.
As for the '\r' characters in the shell script: that's strange
because they are not in my original nor in the attachment as
sent by the Tech-Talk mailing list program to me. All the lines
are terminated by '\n' in my copies.
> 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?
The shell script just alternates between two strings, neither of
which ends with a slash: "/tmp/lys_001.im" and
"/tmp/lys_001.img". So, I'm not sure what you mean. I tried
replacing '/' characters in the two strings with 'x' characters,
and it still succeeds in reproducing the bug.
I tried shortening the strings by one character by removing the
's' in each (i.e. "/tmp/ly_001.im" and "/tmp/ly_001.img"), and
surprisingly it did *not* succeed in reproducing the bug. So,
perhaps it is string length related somehow? The string
"/tmp/lys_001.img" is 16 characters in length.
Here are the results of a few quick tests using reproduce-bug.sh
at a number of string lengths. (I used 'x' instead of '/' to be
sure the '/' character is not contributing to the problem
somehow. The value listed is the longer of the two alternating
strings; the shorter string is the same but without the last 'g'
character.)
Value Length Reproduces Bug
-------------------- ------ --------------
xtmpxlys_0000001.img 20 No
xtmpxlys_000001.img 19 No
xtmpxlys_00001.img 18 No
xtmpxlys_0001.img 17 Yes
xtmpxlys_001.img 16 Yes
xtmpxlys_01.img 15 No
xtmpxlys_1.img 14 No
xtmpxly_1.img 13 No
So, the bug shows up for strings of length 16 or 17 but not for
shorter or longer strings in the tested length range [13-20].
> 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.
Hmm...puzzling.
Thanks,
Lewis
- 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 Mark Rivers
- Next:
Re: edm and other extensions on 64-bit SL machines Janet Anderson
- 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:
EDM widget PV name copy on OS X Eric Norum
- 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