Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8248648

Dacapo24H.java failed "illegal bytecode sequence - method not verified"


    • Subcomponent:
    • CPU:
    • OS:


      The following test failed in the JDK16 CI:


      Here's a snippet from the log file:

      DacapoRunner: java.awt.Toolkit.getDefaultToolkit(): sun.awt.HeadlessToolkit@4420782a
      DacapoRunner: javax.xml.transform.TransformerFactory.newInstance(): com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl@3d7c4d4f
      DacapoRunner: Started benchmark: jython

      The tail of stress stdout is:
      For random generator using seed: 510939874330389042
      To re-run test with same seed value please add "-Djdk.test.lib.random.seed=510939874330389042" to command line.
      Command line: [/opt/mach5/mesos/work_dir/jib-master/install/jdk-16+4-99/linux-x64.jdk/jdk-16/bin/java -jar /opt/mach5/mesos/work_dir/jib-master/download/org/dacapo/309e1fa/dacapo-309e1fa.jar -l]
      [2020-07-01T13:33:12.373460985Z] Gathering output for process 7557
      [2020-07-01T13:33:12.457354481Z] Waiting for completion for process 7557
      [2020-07-01T13:33:12.457528089Z] Waiting for completion finished for process 7557
      Output and diagnostic info for process 7557 was saved into 'pid-7557-output.log'
      avrora batik biojava cassandra eclipse fop graphchi h2 h2o jme jython kafka luindex lusearch pmd sunflow tomcat tradebeans tradesoap xalan zxing
      IMPORTANT NOTICE: This is NOT a release build of the DaCapo suite.
      Since it is not an official release of the DaCapo suite, care must be taken when
      using the suite, and any use of the build must be sure to note that it is not an
      offical release, and should note the relevant git hash.

      Feedback is greatly appreciated. The preferred mode of feedback is via github.
      Please use our github page to create an issue or a pull request.

      Stress process main method is started.
      # A fatal error has been detected by the Java Runtime Environment:
      # Internal Error (macroAssembler_x86.cpp:880), pid=7518, tid=7600
      # fatal error: DEBUG MESSAGE: illegal bytecode sequence - method not verified
      # JRE version: Java(TM) SE Runtime Environment (16.0+4) (build 16-ea+4-99)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (16-ea+4-99, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
      # Problematic frame:
      # V [libjvm.so+0xa3114d] MacroAssembler::debug64(char*, long, long*)+0x3d
      # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S171/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4feb1d45-e894-473e-84d4-36afbdcfb2ab/runs/93448af1-6652-41fb-b44a-ab81f5d587b8/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/core.7518)
      Unsupported internal testing APIs have been used.

      # An error report file with more information is saved as:
      # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S171/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/4feb1d45-e894-473e-84d4-36afbdcfb2ab/runs/93448af1-6652-41fb-b44a-ab81f5d587b8/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/hs_err_pid7518.log
      # If you would like to submit a bug report, please visit:
      # https://bugreport.java.com/bugreport/crash.jsp

      Here's the crashing thread's stack:

      --------------- T H R E A D ---------------

      Current thread (0x00007f5d0c005e30): GCTaskThread "GC Thread#5" [stack: 0x00007f5cb33f1000,0x00007f5cb34f1000] [id=7600]

      Stack: [0x00007f5cb33f1000,0x00007f5cb34f1000], sp=0x00007f5cb34efac0, free space=1018k
      Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0xa3114d] MacroAssembler::debug64(char*, long, long*)+0x3d

      [error occurred during error reporting (printing native stack), id 0xb, SIGSEGV (0xb) at pc=0x00007f5d6f2fa384]

      Since this test run crashed in a GC thread, I'm starting this
      bug off in hotspot/gc. I'm puzzled why in the world a GC
      thread would be calling MacroAssembler::debug64().


          Issue Links



              • Assignee:
                dcubed Daniel Daugherty
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: