JDK-8075118 : JVM stuck in infinite loop during verification
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7u76,8u25,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-03-06
  • Updated: 2017-02-22
  • Resolved: 2015-03-19
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 7 JDK 8 JDK 9 Other
7u101Fixed 8u60Fixed 9 b64Fixed openjdk7uFixed
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
Comments
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 :)
17-03-2015
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
16-03-2015
Reopening as we can readily reproduce this.
16-03-2015
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.
16-03-2015
Moving across JDK for investigation by dev.
13-03-2015