Race in String.contentEquals ( was Re: RFR: 8013395 StringBuffer.toString performance regression impacting embedded benchmarks)

David Holmes david.holmes at oracle.com
Tue May 14 05:22:31 UTC 2013


Thanks Peter! I've filed

8014477
Race condition in String.contentEquals when comparing with StringBuffer

On 14/05/2013 8:34 AM, Peter Levart wrote:
> On 05/14/2013 12:09 AM, Peter Levart wrote:
>> I noticed a synchronization bug in String.contentEquals method. If
>> called with a StringBuffer argument while concurrent thread is
>> modifying the StringBuffer, the method can either throw
>> ArrayIndexOutOfBoundsException or return true even though the content
>> of the StringBuffer has never been the same as the String's.
>>
>> Here's a proposed patch:
>>
>> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.01/
>>
>> Regards, Peter
>
> Or even better (with some code clean-up):
>
> http://cr.openjdk.java.net/~plevart/jdk8-tl/String.contentEquals/webrev.02/

This part is not correct I believe:

1010     private boolean nonSyncContentEquals(AbstractStringBuilder sb) {
1011         char v1[] = value;
1012         char v2[] = sb.getValue();
1013         int n = v1.length;
1014         if (n != v2.length) {
1015             return false;
1016         }

v2 can be larger than v1 if v2 is not being fully used (ie count < length).

David
-----



More information about the core-libs-dev mailing list