VM crashed at StringTable expansion

[coleen.phillimore at oracle.com]

On 2/26/20 1:07 AM, David Holmes wrote:
> Hi,
>
> cc'ing core-libs-dev as this seems to me like a case of "don't do 
> that!". Reflection can be used to "shoot oneself in the foot" and I 
> think that is the case here.
>
> That said, if we can make the VM more resilient without penalizing all 
> the well behaved code, then we should probably do that.

I reopened bug https://bugs.openjdk.java.net/browse/JDK-8233525 with 
this test case.  I agree that we should try not to crash.

Coleen
>
> Thanks,
> David
>
> On 26/02/2020 3:43 pm, 向伟(识月) wrote:
>> Hi，all,
>>
>> When we migrate an application from JDK8 to JDK11, we meet the same 
>> failure with
>> “Test fails with Internal Error (concurrentHashTable.inline.hpp:679), 
>> pid=15229, tid=15260
>> #fatal error: aux_index does not match even or odd 
>> indices(https://bugs.openjdk.java.net/browse/JDK-8233525)”
>> After investigating the issue, we found the root cause as follow:
>> The customer used reflect to modify the object with the result value 
>> of “String.intern()”. That broke the assumption of StringTable.
>> For StringTable in JDK11, it is implemented by the concurrent hash 
>> table, and uses the string value as key.
>> After reflecting, the Node in StringTable is invalid.
>> When the StringTable needs to grow up,  the invalid node is found in 
>> unzip_bucket and reports fatal error as below:
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (concurrentHashTable.inline.hpp:684), pid=110176, 
>> tid=110200
>> #  fatal error: aux_index does not match even or odd indices
>> We create a simple case to reproduce the issue:
>>
>> import java.lang.reflect.Field;
>> import java.lang.reflect.Modifier;
>> public class StringTableTest {
>>      public static void main(String[] args) throws Exception {
>>          Field f = String.class.getDeclaredField("value");
>>          f.setAccessible(true);
>>          f.set("s1".intern(), f.get("s2"));
>>          for (int i = 0; i < 4_000_000; i++) {
>>              ("s_" + i).intern();
>>          }
>>      }
>> }
>>
>> To solve the issue, we have two proposals:
>> 1. when we find the invalid node in unzip_bucket for StringTable, we 
>> discard the node and give a warning.
>> This doesn’t require modification of any user code, and doesn’t 
>> change the existing implementation logic.2. forbid the user to modify 
>> the return value of String.intern().
>>
>> Thanks,
>> Wei Xiang
>>