commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LANG-481) Possible race-conditions in hashCode of the range classes
Date Fri, 23 Jan 2009 19:49:59 GMT

     [ https://issues.apache.org/jira/browse/LANG-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Boris updated LANG-481:
-----------------------

    Description: 
The hashCode() methods of the range classes look very suspicious to me. The value is lazily
initialized, but the calculation is done _on the cached value. With some unlucky timing a
caller may get an incomplete hash.

An unlucky sequence of Code could be something like
T1:        if (hashCode == 0)
T1:            hashCode = 17;
T2:         if (hashCode == 0)
T2:         return hashCode;
T1:            hashCode = 37 * hashCode...........

where T1 and T2 are different threads accessing the method in parallel and T2 gets the wrong
hash "17".

Affected classes are

org.apache.commons.lang.math.DoubleRange
org.apache.commons.lang.math.FloatRange
org.apache.commons.lang.math.IntRange
org.apache.commons.lang.math.LongRange
org.apache.commons.lang.math.NumberRange
org.apache.commons.lang.math.Range

Possible fix: calculate the hash on a temporary variable and finally assign it to the member

  was:
The hashCode() methods of the range classes look very suspicious to me. The value is lazily
initialized, but the calculation is done _on the cached value. With some unlucky timing a
caller may get an incomplete hash.

An unlucky sequence of Code could be something like
{{T1:        if (hashCode == 0)
T1:            hashCode = 17;
T2:         if (hashCode == 0)
T2:         return hashCode;
T1:            hashCode = 37 * hashCode...........}}

where T1 and T2 are different threads accessing the method in parallel and T2 gets the wrong
hash "17".

Affected classes are

org.apache.commons.lang.math.DoubleRange
org.apache.commons.lang.math.FloatRange
org.apache.commons.lang.math.IntRange
org.apache.commons.lang.math.LongRange
org.apache.commons.lang.math.NumberRange
org.apache.commons.lang.math.Range

Possible fix: calculate the hash on a temporary variable and finally assign it to the member


> Possible race-conditions in hashCode of the range classes
> ---------------------------------------------------------
>
>                 Key: LANG-481
>                 URL: https://issues.apache.org/jira/browse/LANG-481
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Boris
>            Priority: Minor
>
> The hashCode() methods of the range classes look very suspicious to me. The value is
lazily initialized, but the calculation is done _on the cached value. With some unlucky timing
a caller may get an incomplete hash.
> An unlucky sequence of Code could be something like
> T1:        if (hashCode == 0)
> T1:            hashCode = 17;
> T2:         if (hashCode == 0)
> T2:         return hashCode;
> T1:            hashCode = 37 * hashCode...........
> where T1 and T2 are different threads accessing the method in parallel and T2 gets the
wrong hash "17".
> Affected classes are
> org.apache.commons.lang.math.DoubleRange
> org.apache.commons.lang.math.FloatRange
> org.apache.commons.lang.math.IntRange
> org.apache.commons.lang.math.LongRange
> org.apache.commons.lang.math.NumberRange
> org.apache.commons.lang.math.Range
> Possible fix: calculate the hash on a temporary variable and finally assign it to the
member

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message