[
https://issues.apache.org/jira/browse/LOGCXX-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thorsten Schöning resolved LOGCXX-420.
--------------------------------------
Resolution: Fixed
Rev 1559522 fixed the issue for us years ago and it didn't ever occured again.
> 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)
