Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1713638493.1260526521787.JavaMail.jira@brutus>
Date: Fri, 11 Dec 2009 10:15:21 +0000 (UTC)
From: "Tim Ellison (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (LANG-481) Possible race-conditions in hashCode
 of the range classes
In-Reply-To: <257814446.1232740199743.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LANG-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789211#action_12789211 ] 

Tim Ellison commented on LANG-481:
----------------------------------

Boris,
Harmony's String#hashCode() is fine, see the discussions on the dev list

http://markmail.org/thread/3ckdhgonbh7xtulg
http://markmail.org/thread/3ckdhgonbh7xtulg


> 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
>             Fix For: 3.0
>
>         Attachments: LANG-481-reordering_datarace.patch, LANG-481.patch
>
>
> 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) // true
> T1:            hashCode = 17;
> T2:         if (hashCode == 0) // now false because hashCode was already set to 17
> T2:         return hashCode; // return 17
> 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.