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

JVM stuck in infinite loop during verification

    Details

    • Subcomponent:
    • Resolved In Build:
      b64
    • CPU:
      x86_64
    • OS:
      windows_7

      Backports

        Description

        FULL PRODUCT VERSION :
        reproductible in all versions since 1.7.0_72

        FULL OS VERSION :
        Ubutun 14.04 64bits
        Windows 7 64bits

        A DESCRIPTION OF THE PROBLEM :
        The application is stuck.
        - JVM is not responding to jstack, jvisualvm, mission control, etc...
        - 1 CPU is stuck @ 100%

        By running gdb on the jvm, we got stuck at :

        (gdb) bt
        #0 0x00007f14d6d083af in ClassVerifier::ends_in_athrow(unsigned int) () from /usr/lib/jvm/java-7-oracle/jre/lib/amd64/server/libjvm.so
        #1 0x00007f14d6d0b56e in ClassVerifier::verify_invoke_init(RawBytecodeStream*, unsigned short, VerificationType, StackMapFrame*, unsigned.

        I believe the infinite while loop causes the issue.

        THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

        THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Did not try

        REGRESSION. Last worked in version 7u71

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        No reprosteps, since I cannot reach the class that beeing loaded that causes the issue.

        Note that I believe it's a class generated by scalac.

        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        No error messages

        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        No workaround

          Activity

          Hide
          aroy Abhijit Roy (Inactive) added a comment -
          Moving across JDK for investigation by dev.
          Show
          aroy Abhijit Roy (Inactive) added a comment - Moving across JDK for investigation by dev.
          Hide
          dholmes David Holmes added a comment -
          Trying to narrow down the class causing the problem. With -Xverify:none the problem can be worked around.

          Using JDK 7u80:

          With -verbose:class and verification we can see the last class loaded is org.multiverse.utils.TodoException, but we can't see which class is loaded next.

          With -verbose:class and no verification we do not even see the loading of org.multiverse.utils.TodoException, so it appears that lack of verification is changing which classes get loaded.

          Using -XX:+VerboseVerification shows the hang occurs while processing org/multiverse/stms/alpha/transactions/AlphaTransaction:

          flags: { flagThisUninit }
          locals: { uninitializedThis, 'org/multiverse/stms/alpha/transactions/AlphaTransaction' }
          stack: { uninitializedThis, 'org/multiverse/stms/alpha/transactions/AlphaTransaction' }
          offset = 41, opcode = invokespecial
          ^Z

          but javap has no issues examining that class:


          Classfile /export/users/dh198349/tests/samson/org/multiverse/stms/alpha/transactions/AlphaTransaction.class
            Last modified Feb 15, 2011; size 572 bytes
            MD5 checksum 235e7b94325518f89dabf48b4e5a676a
            Compiled from "AlphaTransaction.java"
          public interface org.multiverse.stms.alpha.transactions.AlphaTransaction extends org.multiverse.api.Transaction
            SourceFile: "AlphaTransaction.java"
            RuntimeVisibleAnnotations:
              0: #8(#9=s#10,#11=s#12)
            minor version: 0
            major version: 50
            flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT
          Constant pool:
             #1 = Utf8 org/multiverse/stms/alpha/transactions/AlphaTransaction
             #2 = Class #1 // org/multiverse/stms/alpha/transactions/AlphaTransaction
             #3 = Utf8 java/lang/Object
             #4 = Class #3 // java/lang/Object
             #5 = Utf8 org/multiverse/api/Transaction
             #6 = Class #5 // org/multiverse/api/Transaction
             #7 = Utf8 AlphaTransaction.java
             #8 = Utf8 Lorg/multiverse/instrumentation/InstrumentationStamp;
             #9 = Utf8 instrumentorName
            #10 = Utf8 AlphaStmInstrumentor
            #11 = Utf8 instrumentorVersion
            #12 = Utf8 0.6
            #13 = Utf8 openForRead
            #14 = Utf8 (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;
            #15 = Utf8 openForWrite
            #16 = Utf8 openForCommutingWrite
            #17 = Utf8 openForConstruction
            #18 = Utf8 SourceFile
            #19 = Utf8 RuntimeVisibleAnnotations
          {
            public abstract org.multiverse.stms.alpha.AlphaTranlocal openForRead(org.multiverse.stms.alpha.AlphaTransactionalObject);
              Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;
              flags: ACC_PUBLIC, ACC_ABSTRACT

            public abstract org.multiverse.stms.alpha.AlphaTranlocal openForWrite(org.multiverse.stms.alpha.AlphaTransactionalObject);
              Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;
              flags: ACC_PUBLIC, ACC_ABSTRACT

            public abstract org.multiverse.stms.alpha.AlphaTranlocal openForCommutingWrite(org.multiverse.stms.alpha.AlphaTransactionalObject);
              Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;
              flags: ACC_PUBLIC, ACC_ABSTRACT

            public abstract org.multiverse.stms.alpha.AlphaTranlocal openForConstruction(org.multiverse.stms.alpha.AlphaTransactionalObject);
              Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;
              flags: ACC_PUBLIC, ACC_ABSTRACT
          }


          Problem does not reproduce with JDK 8:

          > java -showversion -Xverify:all -cp multiverse-alpha.jar:. Main
          java version "1.8.0"
          Java(TM) SE Runtime Environment (build 1.8.0-b132)
          Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode)

          Mar 16, 2015 1:40:47 AM org.multiverse.api.GlobalStmInstance <clinit>
          INFO: Initializing GlobalStmInstance using factoryMethod 'org.multiverse.stms.alpha.AlphaStm.createFast'.
          Mar 16, 2015 1:40:47 AM org.multiverse.stms.alpha.AlphaStm <init>
          INFO: Created a new AlphaStm instance
          Mar 16, 2015 1:40:47 AM org.multiverse.api.GlobalStmInstance <clinit>
          INFO: Successfully initialized GlobalStmInstance using factoryMethod 'org.multiverse.stms.alpha.AlphaStm.createFast'.


          However problem does occur with latest 8u60, which suggests a verifier change, possibly via a CPU.

          Problem also reproduces in JDK 9.



          Show
          dholmes David Holmes added a comment - Trying to narrow down the class causing the problem. With -Xverify:none the problem can be worked around. Using JDK 7u80: With -verbose:class and verification we can see the last class loaded is org.multiverse.utils.TodoException, but we can't see which class is loaded next. With -verbose:class and no verification we do not even see the loading of org.multiverse.utils.TodoException, so it appears that lack of verification is changing which classes get loaded. Using -XX:+VerboseVerification shows the hang occurs while processing org/multiverse/stms/alpha/transactions/AlphaTransaction: flags: { flagThisUninit } locals: { uninitializedThis, 'org/multiverse/stms/alpha/transactions/AlphaTransaction' } stack: { uninitializedThis, 'org/multiverse/stms/alpha/transactions/AlphaTransaction' } offset = 41, opcode = invokespecial ^Z but javap has no issues examining that class: Classfile /export/users/dh198349/tests/samson/org/multiverse/stms/alpha/transactions/AlphaTransaction.class   Last modified Feb 15, 2011; size 572 bytes   MD5 checksum 235e7b94325518f89dabf48b4e5a676a   Compiled from "AlphaTransaction.java" public interface org.multiverse.stms.alpha.transactions.AlphaTransaction extends org.multiverse.api.Transaction   SourceFile: "AlphaTransaction.java"   RuntimeVisibleAnnotations:     0: #8(#9=s#10,#11=s#12)   minor version: 0   major version: 50   flags: ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT Constant pool:    #1 = Utf8 org/multiverse/stms/alpha/transactions/AlphaTransaction    #2 = Class #1 // org/multiverse/stms/alpha/transactions/AlphaTransaction    #3 = Utf8 java/lang/Object    #4 = Class #3 // java/lang/Object    #5 = Utf8 org/multiverse/api/Transaction    #6 = Class #5 // org/multiverse/api/Transaction    #7 = Utf8 AlphaTransaction.java    #8 = Utf8 Lorg/multiverse/instrumentation/InstrumentationStamp;    #9 = Utf8 instrumentorName   #10 = Utf8 AlphaStmInstrumentor   #11 = Utf8 instrumentorVersion   #12 = Utf8 0.6   #13 = Utf8 openForRead   #14 = Utf8 (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;   #15 = Utf8 openForWrite   #16 = Utf8 openForCommutingWrite   #17 = Utf8 openForConstruction   #18 = Utf8 SourceFile   #19 = Utf8 RuntimeVisibleAnnotations {   public abstract org.multiverse.stms.alpha.AlphaTranlocal openForRead(org.multiverse.stms.alpha.AlphaTransactionalObject);     Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;     flags: ACC_PUBLIC, ACC_ABSTRACT   public abstract org.multiverse.stms.alpha.AlphaTranlocal openForWrite(org.multiverse.stms.alpha.AlphaTransactionalObject);     Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;     flags: ACC_PUBLIC, ACC_ABSTRACT   public abstract org.multiverse.stms.alpha.AlphaTranlocal openForCommutingWrite(org.multiverse.stms.alpha.AlphaTransactionalObject);     Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;     flags: ACC_PUBLIC, ACC_ABSTRACT   public abstract org.multiverse.stms.alpha.AlphaTranlocal openForConstruction(org.multiverse.stms.alpha.AlphaTransactionalObject);     Signature: (Lorg/multiverse/stms/alpha/AlphaTransactionalObject;)Lorg/multiverse/stms/alpha/AlphaTranlocal;     flags: ACC_PUBLIC, ACC_ABSTRACT } Problem does not reproduce with JDK 8: > java -showversion -Xverify:all -cp multiverse-alpha.jar:. Main java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Server VM (build 25.0-b70, mixed mode) Mar 16, 2015 1:40:47 AM org.multiverse.api.GlobalStmInstance <clinit> INFO: Initializing GlobalStmInstance using factoryMethod 'org.multiverse.stms.alpha.AlphaStm.createFast'. Mar 16, 2015 1:40:47 AM org.multiverse.stms.alpha.AlphaStm <init> INFO: Created a new AlphaStm instance Mar 16, 2015 1:40:47 AM org.multiverse.api.GlobalStmInstance <clinit> INFO: Successfully initialized GlobalStmInstance using factoryMethod 'org.multiverse.stms.alpha.AlphaStm.createFast'. However problem does occur with latest 8u60, which suggests a verifier change, possibly via a CPU. Problem also reproduces in JDK 9.
          Hide
          dholmes David Holmes added a comment -
          Reopening as we can readily reproduce this.
          Show
          dholmes David Holmes added a comment - Reopening as we can readily reproduce this.
          Hide
          hseigel Harold Seigel added a comment -
          It seems to be looping while examining bytecodes 99 through 106. Note that the target of the third entry in the exception table is within the bytecode range being protected.

                  98: athrow
                  99: astore 4
                 101: invokestatic #80 // Method org/multiverse/api/ThreadLocalTransaction.clearThreadLocalTransaction:()V
                 104: aload 4
                 106: athrow
                 107: return
                Exception table:
                   from to target type
                      40 54 60 Class java/lang/Throwable
                      40 54 99 any
                      60 101 99 any
          Show
          hseigel Harold Seigel added a comment - It seems to be looping while examining bytecodes 99 through 106. Note that the target of the third entry in the exception table is within the bytecode range being protected.         98: athrow         99: astore 4        101: invokestatic #80 // Method org/multiverse/api/ThreadLocalTransaction.clearThreadLocalTransaction:()V        104: aload 4        106: athrow        107: return       Exception table:          from to target type             40 54 60 Class java/lang/Throwable             40 54 99 any             60 101 99 any
          Hide
          dholmes David Holmes added a comment -
          Yes the exception table looks incorrect. The second line makes no sense give that "any" exception is-a java/lang/Throwable.

          Still it should either verify or not verify :)
          Show
          dholmes David Holmes added a comment - Yes the exception table looks incorrect. The second line makes no sense give that "any" exception is-a java/lang/Throwable. Still it should either verify or not verify :)
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b1bcd763171a
          User: hseigel
          Date: 2015-03-19 20:32:07 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b1bcd763171a User: hseigel Date: 2015-03-19 20:32:07 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b1bcd763171a
          User: lana
          Date: 2015-05-13 21:19:48 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b1bcd763171a User: lana Date: 2015-05-13 21:19:48 +0000

            People

            • Assignee:
              hseigel Harold Seigel
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: