[LOGCXX-420] Possible out_of_range exception for millisecond formats in CachedDateFormat

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.10.0
• Component/s: Layout
• Assignee: Thorsten Schöning
• Reporter: Thorsten Schöning
• Created: 19/Jan/14 16:40
• Updated: 12/Feb/14 09:37
• Resolved: 19/Jan/14 16:47

Description

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.

Issue Links

• relates to: LOGCXX-425 exceptions in CachedDateFormatTestCase after LOGCXX-420