Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 10
    • Fix Version/s: 10
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b31

      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.

        Issue Links

          Activity

          Hide
          iklam Ioi Lam added a comment -
          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).
          Show
          iklam Ioi Lam added a comment - 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 ).
          Hide
          thartmann Tobias Hartmann added a comment -
          ILW = Tests fail with ClassNotFoundException (testbug), 4 tests, no workaround = MMH = P3
          Show
          thartmann Tobias Hartmann added a comment - ILW = Tests fail with ClassNotFoundException (testbug), 4 tests, no workaround = MMH = P3
          Hide
          iignatyev Igor Ignatyev added a comment -
          > 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?
          Show
          iignatyev Igor Ignatyev added a comment - > 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?
          Hide
          kvn Vladimir Kozlov added a comment -
          I hit next test too:
          compiler/jvmci/TestJVMCIPrintProperties.java
          Show
          kvn Vladimir Kozlov added a comment - I hit next test too: compiler/jvmci/TestJVMCIPrintProperties.java
          Hide
          iklam Ioi Lam added a comment -
          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.

          Show
          iklam Ioi Lam added a comment - 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.
          Hide
          iignatyev Igor Ignatyev added a comment -
          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.
          Show
          iignatyev Igor Ignatyev added a comment - 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.
          Hide
          iklam Ioi Lam added a comment -
          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.
          Show
          iklam Ioi Lam added a comment - 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.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk10/hs/rev/601807573d40
          User: iklam
          Date: 2017-10-09 22:43:24 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk10/hs/rev/601807573d40 User: iklam Date: 2017-10-09 22:43:24 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk10/master/rev/601807573d40
          User: jwilhelm
          Date: 2017-11-04 02:58:06 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk10/master/rev/601807573d40 User: jwilhelm Date: 2017-11-04 02:58:06 +0000

            People

            • Assignee:
              iklam Ioi Lam
              Reporter:
              iklam Ioi Lam
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: