[jira] Resolved: (HARMONY-6405) [classlib][luni] String.equals() is not thread-safe

["Tim Ellison (JIRA)" <ji...@apache.org>]

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

Tim Ellison resolved HARMONY-6405.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0M13

Agreed.  Thanks Sebb, patch applied at repo revision r892226.

Please check this fixes the issue.


> [classlib][luni] String.equals() is not thread-safe
> ---------------------------------------------------
>
>                 Key: HARMONY-6405
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6405
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M12
>            Reporter: Sebb
>            Assignee: Tim Ellison
>             Fix For: 5.0M13
>
>
> AFAICT, String.equals() is not thread-safe.
> It includes the following code (wrapped for ease of reference):
> if (count != s.count     // 1
> || (hashCode != s.hashCode     // 2 
>   && hashCode != 0     // 3
>   && s.hashCode != 0)) {     //4
> return false;     //5
> Suppose both Strings refer to the same sequence of characters, so equals() should return true.
> Suppose the hashCode has not yet been calculated for "s", but it has been calculated for "this".
> At the start:  hashCode != s.hashCode and count == s.count
> Line 1 all threads see equality , because count is final.
> Line 2 thread A sees hashCode != s.hashCode, i.e. potentially different Strings
> Thread B then does s.hashCode() and sets s.hashCode !=0
> Line 3 thread A sees hashCode !=0, which is correct
> Line 4 thread A sees s.hashCode !=0, which is different from before
> Line 5 thread A returns false, whereas thread B will return true.
> One possible solution is to fetch the hashCodes into local variables; the values cannot then change unexpectedly.
> Although thread A won't see the updated hashCode for "s", that does not matter, because only non-zero codes matter for this comparison.
> It should also work if the hashCodes were compared after checking for non-zero, but it would be less fragile (and likely quicker) to fetch each value once.

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