Incorrect validation of DST in java.util.SimpleTimeZone
Venkateswara R Chintala
venkatec at linux.vnet.ibm.com
Fri Nov 10 12:18:49 UTC 2017
Looks like the patch attached earlier is not visible. As this is my
first contribution, please let me know how I can send the patch for review.
On 10/11/17 5:37 PM, Venkateswara R Chintala wrote:
> In a multi-threaded environment, when java.util.SimpleTimeZone object
> is used to create a default timezone, there can be a race condition
> between the methods java.util.Timezone.getDefault() and
> java.util.Timezone.getDefaultRef() 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 time/year
> values, then the cache values (cacheYear, cacheStart, cacheEnd) can
> become inconsistent which leads to incorrect DST determination.
> 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.
> We preferred the second option as synchronization is more expensive.
> We have attached the patch and jtreg testcase. Please review.
More information about the core-libs-dev