JDK-8236661 : Launcher test PatchSystemModules.java fails frequently after JDK-8234049
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 14
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2020-01-06
  • Updated: 2020-01-29
  • Resolved: 2020-01-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14 JDK 15
14 b32Fixed 15Fixed
Related Reports
Relates :  
JDK-8234049 - Implementation of Memory Access API (Incubator)
Description
test/jdk/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java

This test start failing frequently after JDK-8234049, failure reproducible with windows-x64 in 20 times of run.

In case of fail, it failed in PatchSystemModules.test():

Command line: [C:\\users\\opc\\sandbox_keepme\\jdk\\bin\\java.exe --module-path mods -m m1/p1.Main 1]
...
Command line: [C:\\users\\opc\\sandbox_keepme\\jdk\\bin\\java.exe --patch-module java.base=patches\\java.base --module-path mods -m m1/p1.Main 1]
[2020-01-03T10:05:00.529828300Z] Gathering output for process 20324
Error occurred during initialization of boot layer
java.lang.InternalError: java.lang.NullPointerException
Caused by: java.lang.NullPointerException

Error occurred during initialization of boot layer
java.lang.InternalError: java.lang.NullPointerException
Caused by: java.lang.NullPointerException
...
test PatchSystemModules.test(): failure
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:94)
	at org.testng.Assert.failNotEquals(Assert.java:496)
	at org.testng.Assert.assertTrue(Assert.java:42)
	at org.testng.Assert.assertTrue(Assert.java:52)
	at PatchSystemModules.runTest(PatchSystemModules.java:216)
	at PatchSystemModules.test(PatchSystemModules.java:119)
...
===============================================
tools/launcher/modules/patch/systemmodules/PatchSystemModules.java
Total tests run: 4, Failures: 1, Skips: 0
===============================================
Comments
URL: https://hg.openjdk.java.net/jdk/jdk14/rev/8b9577d77bba User: bpb Date: 2020-01-14 19:06:45 +0000
14-01-2020
Yes, isSync can be changed to check VM.isModuleSystemInited so that it doesn't initialize the class that defines the extended map modes.
13-01-2020
[~alanb] In the comment above do you instead mean to have FileChannelImpl.isSync() return false when VM.isModuleSystemInited() returns false?
13-01-2020
And with below patch, got more info: diff -r 28a926d489151147fac42e86f9beabbe224cb287 src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java --- a/src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java Mon Jan 13 08:29:32 2020 +0530 +++ b/src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java Sun Jan 12 22:32:18 2020 -0800 @@ -59,8 +59,9 @@ Objects.requireNonNull(jimage); try { return readers.computeIfAbsent(jimage, OPENER); - } catch (UncheckedIOException io) { - throw io.getCause(); + } catch (Throwable t) { + t.printStackTrace(); + throw new IOException(t.getCause()); } } java.lang.InternalError: java.lang.NullPointerException at java.base/jdk.internal.misc.ExtendedMapMode.<clinit>(ExtendedMapMode.java:50) at java.base/sun.nio.ch.FileChannelImpl.isSync(FileChannelImpl.java:1119) at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:994) at java.base/jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:132) at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:224) at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:238) at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:67) at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:71) at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:71) at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:68) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708) at java.base/jdk.internal.jimage.ImageReaderFactory.get(ImageReaderFactory.java:61) at java.base/jdk.internal.jimage.ImageReaderFactory.getImageReader(ImageReaderFactory.java:86) at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.<clinit>(SystemModuleFinders.java:383) at java.base/jdk.internal.module.SystemModuleFinders.ofModuleInfos(SystemModuleFinders.java:236) at java.base/jdk.internal.module.SystemModuleFinders.ofSystem(SystemModuleFinders.java:199) at java.base/jdk.internal.module.ModuleBootstrap.boot(ModuleBootstrap.java:209) at java.base/java.lang.System.initPhase2(System.java:2071) Caused by: java.lang.NullPointerException at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:256) at java.base/jdk.internal.misc.ExtendedMapMode.lambda$static$0(ExtendedMapMode.java:45) at java.base/java.security.AccessController.doPrivileged(AccessController.java:554) at java.base/jdk.internal.misc.ExtendedMapMode.<clinit>(ExtendedMapMode.java:46) ... 17 more Error occurred during initialization of boot layer java.lang.ExceptionInInitializerError Caused by: java.io.UncheckedIOException: java.io.IOException: java.lang.NullPointerException
13-01-2020
I did some analysis of the code before/after JEP 370, and it looks like what really changed is that, before the change, the ExtendedMapMode constants were never accessed if a buffer was mapped using the READ_ONLY mode (which, coincidentally is what the JRT image reader does). But this is indeed a sign of a wider problem, which was also there before this change - we can either tweak the new code so that isSync() returns false when READ_ONLY is used, or do as Alan suggested and always return false when we're in module initialization stage.
13-01-2020
The stack trace suggests this is an exploded build (or a run with -Ddk.system.module.finder.disableFastPath). In this "mode", there is a lot of code executed in early startup (early part of initPhase2) before java.base is defined to the VM. Class::getModule returns null during this time and code executed in early part of initPhase2 needs to allow for be very careful. I think the simplest fix to this issue is for FileChannelImpl.isSync to return false when isModuleSystemInited. This will defer the initialization of ExtendedMapMode until after the module system has been initialized. It may also be worth changing MethodHandles.privateLookupIn to check if the caller module is null for cases where it is accidentally used during early startup.
13-01-2020