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