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

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

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 10
    • None
    • core-libs
    • None
    • b36
    • generic
    • generic
    • Verified

      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.

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

              Created:
              Updated:
              Resolved: