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:
> Hi,
>
> 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.
>

-- 
Regards
-Venkat



More information about the core-libs-dev mailing list