The native implementation of ProcessEnvironment.environ[1] iterates over the global `environ` variable twice, expecting it to be the same length in both iterations. However, any interleaving call to setenv/putenv could change the contents. One such call is from libjli.dylib on macOS, which sets an environment variable[2] after the JVM has been booted.
We see this with some frequency during GraalVM testing with stack traces such as:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 145
at java.lang.ProcessEnvironment.environ(java.base@11.0.10/Native Method)
at java.lang.ProcessEnvironment.<clinit>(java.base@11.0.10/ProcessEnvironment.java:70)
at java.lang.System.getenv(java.base@11.0.10/System.java:1049)
at org.graalvm.compiler.options.ModuleSupport.<clinit>(jdk.internal.vm.compiler/ModuleSupport.java:31)
[1] https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/unix/native/libjava/ProcessEnvironment_md.c#L50
[2] https://github.com/openjdk/jdk/blob/739769c8fc/src/java.base/macosx/native/libjli/java_md_macosx.m#L862
We see this with some frequency during GraalVM testing with stack traces such as:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 145
at java.lang.ProcessEnvironment.environ(java.base@11.0.10/Native Method)
at java.lang.ProcessEnvironment.<clinit>(java.base@11.0.10/ProcessEnvironment.java:70)
at java.lang.System.getenv(java.base@11.0.10/System.java:1049)
at org.graalvm.compiler.options.ModuleSupport.<clinit>(jdk.internal.vm.compiler/ModuleSupport.java:31)
[1] https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/unix/native/libjava/ProcessEnvironment_md.c#L50
[2] https://github.com/openjdk/jdk/blob/739769c8fc/src/java.base/macosx/native/libjli/java_md_macosx.m#L862
- relates to
-
JDK-8274397 [macOS] Stop setting env. var JAVA_MAIN_CLASS_<pid> in launcher code
-
- Resolved
-