[
https://issues.apache.org/jira/browse/LOGCXX-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klemens Schölhorn updated LOGCXX-506:
-------------------------------------
Attachment: 0003-CachedDateFormat-Correct-fix-for-handling-ts-with-65.patch
> CachedDateFormat reuses timestamps without updating milliseconds after
> formatting timestamp with ms == 654
> ----------------------------------------------------------------------------------------------------------
>
> Key: LOGCXX-506
> URL: https://issues.apache.org/jira/browse/LOGCXX-506
> Project: Log4cxx
> Issue Type: Bug
> Affects Versions: 0.10.0, 0.11.0
> Reporter: Klemens Schölhorn
> Assignee: Thorsten Schöning
> Priority: Critical
> Fix For: 0.11.0
>
> Attachments:
> 0001-CachedDateFormat-Remove-magic-numbers-from-header.patch,
> 0002-CachedDateFormat-Fix-handling-of-ts-with-654-as-ms-p.patch,
> 0003-CachedDateFormat-Correct-fix-for-handling-ts-with-65.patch
>
>
> findMillisecondStart tries to find the position of the milliseconds in a
> formatted timestamp by comparing the formatting to one where the millisecond
> part of the timestamp was replaced with 654. If the timestamp already has
> this millisecond part, it will switch to a different value: 987.
> However the check if it should switch to 987 is broken, as it is comparing
> the magic number in microseconds to the millisecond part of the timestamp in
> milliseconds, so this always results in false. This leads to the comparison
> timestamp being identical and the function falsely returning NO_MILLISECONDS.
> The end result is that if the first timestamp we format since the beginning
> of the current second has 654 as milliseconds, for all following formatted
> timestamps the milliseconds will be identical when within the same second, as
> the code never tries to find the millisecond start again, but still happily
> uses the cache within one second without updating milliseconds.
> The fix itself is pretty easy: We just need to compare using the correct
> units in findMillisecondStart.
>
> I could reproduce this on the v0_10_0 tag and on latest master under RHEL
> 7.4. Patches with a testcase and the fix against master are attached (they
> can basically be also applied to 0.10, although the code formatting
> changed...).
> The first patch removes the magic numbers from the header and puts them next
> to the magic strings. This is not necessary for the fix, but it improves
> readability a lot (and maybe breaks abi?).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
