JDK-8188828 : Intermittent ClassNotFoundException: jdk.test.lib.Platform for compiler tests
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-05
  • Updated: 2021-10-21
  • Resolved: 2017-10-09
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 10
10 b31Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
A few intermittent failures, mostly on Solaris. 

compiler/jvmci/TestValidateModules.java
compiler/profiling/spectrapredefineclass/Launcher.java
compiler/profiling/spectrapredefineclass_classloaders/Launcher.java
compiler/startup/StartupOutput.java

It's probably caused a preceding test that was missing an "@build" tag.
Comments
URL: http://hg.openjdk.java.net/jdk10/master/rev/601807573d40 User: jwilhelm Date: 2017-11-04 02:58:06 +0000
04-11-2017

URL: http://hg.openjdk.java.net/jdk10/hs/rev/601807573d40 User: iklam Date: 2017-10-09 22:43:24 +0000
09-10-2017

Igor, thanks for your suggestion. It turns out that ClassFileInstaller does not depend on jdk.test.lib.Platform, but the cuplrit is jdk.test.lib.FileInstaller: FileInstaller -> Utils -> JDKToolLauncher -> Platform I looked at one of the failed tests, and the failure sequence is jtreg \ compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java \ compiler/jvmci/events/JvmciShutdownEventTest.java \ compiler/profiling/spectrapredefineclass/Launcher.java The error is 100% reproducible. If I remove the (very simple) dependency from FileInstaller -> Utils, the error is gone.
06-10-2017

IIRC, to bump into this problem, a test should have these properties: - has more than one @library - depends on class Foo from library A which depends on class Bar from another library B - has an implicit/explicit build for class Baz from libraries which depends on class Bar the most common example is A=/, B=/test/lib, Bar=jdk.test.lib.Platform, Baz=ClassFileInstaller. so we can also work around this problem by removing dependencies on jdk.test.lib.* classes from ClassFileInstaller.
06-10-2017

The problem is there are lots of tests that don't have "/" in their @library line: open/test/hotspot/jtreg/compiler$ find . -name \*.java | xargs grep @library | grep -v ' / ' | grep -v ' /$' | wc 122 495 9112 It will be hard to maintain the code if we have to manually insert @build at the right place. Since this problem happens mostly with the compiler tests (due to the extensive use of "@library /"), I am looking at the test definition now and see if there's a way to insert an artificial test group to run a bunch of dummy tests which simply does: /* @test * @library /test/lib * @build jdk.test.lib.* jdk.test.lib.process.* */ That way, before the compiler tests are executed, we already have the test library compiled.
06-10-2017

I hit next test too: compiler/jvmci/TestJVMCIPrintProperties.java
06-10-2017

> All 4 test cases use "@library /test/lib" without "/", and runs into the "split library" problem. shouldn't the latest version of jtreg solve "split library" problem for such cases?
06-10-2017

ILW = Tests fail with ClassNotFoundException (testbug), 4 tests, no workaround = MMH = P3
06-10-2017

This has the same root cause as stated in https://bugs.openjdk.java.net/browse/CODETOOLS-7901986?focusedCommentId=14108320&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14108320 All 4 test cases use "@library /test/lib" without "/", and runs into the "split library" problem. I'll do a band-aid fix and add "@build jdk.test.lib.* jdk.test.lib.process.*" into these 4 tests (same fix as in JDK-8186151).
06-10-2017