VM crashed at StringTable expansion

David Holmes david.holmes at oracle.com
Wed Feb 26 06:07:03 UTC 2020


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.


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

More information about the core-libs-dev mailing list