Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8191216

SimpleTimeZone.clone() has a data race on cache fields

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b36
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Description

      In a multi-threaded environment, when java.util.SimpleTimeZone object is used for a default timezone, there can be a race condition between cloning the defaultTimeZone instance in Timezone.getDefault() method and internal read-only multi-threaded usage of defaultTimeZone instance (obtained internally by package-private Timezone.getDefaultRef() method) which can result in inconsistency of cache that is used to validate a particular time/date in DST.

      When a thread is cloning a default timezone object (SimpleTimeZone) and at the same time if a different thread modifies the cache values (cacheYear, cacheStart, cacheEnd), they can be cloned in inconsistent state which leads to incorrect DST determination when the cloned instance is used for calculations.

      We considered two approaches to fix the issue.

      1)Synchronize access to cloning default timezone object when cache is being modified.

      2)Invalidate the cache while returning the clone.

        Attachments

          Activity

            People

            • Assignee:
              plevart Peter Levart
              Reporter:
              plevart Peter Levart
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: