RFR (S) 8204055: SIGSEGV in java -XX:
David Holmes
david.holmes at oracle.com
Thu May 31 07:13:04 UTC 2018
On 31/05/2018 4:34 PM, Calvin Cheung wrote:
> Hi David,
>
> Looks good.
Thanks Calvin.
> Just a small nit in stringUtils.cpp for which I don't need to see
> another webrev.
>
> 52 // filter out zero-length strings else we will underflow on
> len-1 below
> 53 if (len1 == 0 || len2 == 0) {
> 54 return 0.0;
> 55 }
>
> How about moving the above right before the calculation of "total" (line
> 49)?
Yes I can do that.
Cheers,
David
> thanks,
> Calvin
>
> On 5/30/18, 10:55 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204055
>> webrev: http://cr.openjdk.java.net/~dholmes/8204055/webrev/
>>
>>
>> The SEGV was introduced with the fuzzy matching flag logic refactoring
>> in JDK-8198554. In:
>>
>> double StringUtils::similarity(const char* str1, size_t len1, const
>> char* str2, size_t len2) {
>> size_t total = len1 + len2;
>>
>> size_t hit = 0;
>> for (size_t i = 0; i < len1 - 1; i++) {
>> for (size_t j = 0; j < len2 - 1; j++) {
>> if ((str1[i] == str2[j]) && (str1[i+1] == str2[j+1])) {
>> ++hit;
>> break;
>> }
>> }
>> }
>>
>> If len2 is zero (which it is in this case) we have passed it as an
>> unsigned size_t, so len2-1 gives a massive positive value and so we
>> enter the loop and try to access str2[n] for some n>0 and we get a SEGV.
>>
>> The original code had:
>>
>> - for (int j = 0; j < (int) len2 -1; ++j) {
>>
>> so the huge positive value reverted to a small negative value and we
>> don't enter the loop.
>>
>> The fix applied is to check explicitly for lengths of zero.
>>
>> Added missing testcases to:
>>
>> test/hotspot/gtest/logging/test_logConfiguration.cpp
>> test/hotspot/jtreg/runtime/CommandLine/UnrecognizedVMOption.java
>>
>> verified they both crash before the fix.
>>
>> Testing (in progress): tier1,2,3 per mach5 CI
>>
>> Thanks,
>> David
More information about the hotspot-runtime-dev
mailing list