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

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