Thorsten Schöning created LOGCXX-420:
----------------------------------------
Summary: Possible out_of_range exception for millisecond formats
in CachedDateFormat
Key: LOGCXX-420
URL: https://issues.apache.org/jira/browse/LOGCXX-420
Project: Log4cxx
Issue Type: Bug
Components: Layout
Affects Versions: 0.10.0
Reporter: Thorsten Schöning
Assignee: Thorsten Schöning
In 2010 we recognized what I think is a bug in
CachedDateFormat::findMillisecondStart which leads to out_of_range exceptions
depending on the time when log statements were issued. We always log with
milliseconds enabled and the mentioned method seems to incorrectly assume it
always needs to compare 3 characters. The following lines are some debug output
made those days for a working log statement:
ConversionPattern %d{yyyy-MM-dd HH:mm:ss,SSS}
formatted[i] 2010-08-12 11:04:50,406
plusMagic[i] 2010-08-12 11:04:50,654
plusZero 2010-08-12 11:04:50,000
plusZero.length() 23
formatted.length() 23
i 20
magicString 654
formattedMillis 406
zeroString ""
i is 20 and we have 3 characters for milliseconds to compare, therefore no
problem. Next the output for a statement where the execeptions got thrown:
ConversionPattern %d{yyyy-MM-dd HH:mm:ss,SSS}
formatted[i] 2010-08-12 11:04:50,609
plusMagic[i] 2010-08-12 11:04:50,654
plusZero 2010-08-12 11:04:50,000
plusZero.length() 23
formatted.length() 23
i 21
magicString 654
formattedMillis 609
zeroString ""
Now i is 21 because the first characters of the milliseconds are equal,
therefore we can't compare additional 3 characters, but only 2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
