JDK-8058975 : NoSuchMethodException: j.l.i.MethodHandle.linkToStatic during JVM startup cause fatal error: ExceptionMark destructor expects no pending exceptions
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u60,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2014-09-23
  • Updated: 2016-05-25
  • Resolved: 2015-04-13
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 8 JDK 9
8u60Resolved 9Resolved
Related Reports
Relates :  
Relates :  
Description
Starting from 8u40-b06 JVM crashes with fatal error: ExceptionMark destructor expects no pending exceptions:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/jprt/T/P1/093631.amurillo/s/hotspot/src/share/vm/utilities/exceptions.cpp:427), pid=32637, tid=140625270261504
#  fatal error: ExceptionMark destructor expects no pending exceptions
#
# JRE version: Java(TM) SE Runtime Environment (8.0_40-b06) (build 1.8.0_40-internal-fastdebug-201409190936.amurillo.hs25-40-b11-jdk8u4-b06)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b11-fastdebug compiled mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

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

Current thread (0x0000000000da7000):  JavaThread "main" [_thread_in_vm, id=32640, stack(0x00007fe5df37c000,0x00007fe5df47d000)]

Stack: [0x00007fe5df37c000,0x00007fe5df47d000],  sp=0x00007fe5df47b5a0,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xfddf92]  VMError::report_and_die()+0x2d2
V  [libjvm.so+0x720c30]  report_fatal(char const*, int, char const*)+0x80
V  [libjvm.so+0x7d41e7]  ExceptionMark::~ExceptionMark()+0x147
V  [libjvm.so+0xf5ca34]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x424
V  [libjvm.so+0xa5eeb4]  JNI_CreateJavaVM+0xb4
C  [libjli.so+0x7c0e]  JavaMain+0x9e
C  [libpthread.so.0+0x69ca]  start_thread+0xca


According to the test log, the pending exception is "java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,MemberName)Object/invokeStatic":
----------System.out:(32/2143)----------
CodeCache: size=4096Kb used=3577Kb max_used=3577Kb free=518Kb
 bounds [0x00007fe5dc0de000, 0x00007fe5dc4de000, 0x00007fe5dc4de000]
 total_blobs=950 nmethods=369 adapters=500
 compilation: disabled (not enough contiguous free space left)
java.lang.InternalError 
 - klass: 'java/lang/InternalError'
 - ---- fields (total size 4 words):
 - private transient 'backtrace' 'Ljava/lang/Object;' @12  a 'java/lang/Object'[4]  (ec099f20 ec09a460)
 - private 'detailMessage' 'Ljava/lang/String;' @16  "java.lang.NoSuchMethodException: no such method: java.lang.invoke.MethodHandle.linkToStatic(Object,MemberName)Object/invokeStatic" (ec09a460 ec099aa0)
 - private 'cause' 'Ljava/lang/Throwable;' @20  a 'java/lang/NoSuchMethodException' (ec099aa0 eb592218)
 - private 'stackTrace' '[Ljava/lang/StackTraceElement;' @24  a 'java/lang/StackTraceElement'[0]  (eb592218 eb592820)
 - private strict 'suppressedExceptions' 'Ljava/util/List;' @28  a 'java/util/Collections$UnmodifiableRandomAccessList' (eb592820 1)

Issue could be reproduced only w/ -Xcomp.
I was not able to reproduce it w/ 8u40-b05 as well as w/ 9-b31.
Comments
Verified that exceptions during MH stub generation don't cause VM crashes anymore. VM gracefully shutdowns with detailed information about the exception being printed.
13-04-2015

won't it be fixed by JDK-8064875?
26-11-2014

I would like to emphasize that the problem not only in exception, but also in JVM's crash.
26-11-2014

Retriage: ILW=VM cant be initalized with very small code cache, reproducible, none = MLH=P4
26-11-2014

Who wrote that test? hg log doesn't reveal anything useful.
26-09-2014

ILW=Fatal VM error, reproducible, none = HMH=P1 Why is the codecache set?
24-09-2014

The test specifies -XX:ReservedCodeCacheSize=4m. During bootstrap we initialize some core java.lang.invoke classes (see Threads::initialize_jsr292_core_classes()) and produce some MH intrinsics as a side effect.
23-09-2014

We seem to be missing an exception check somewhere in the init process, such that we hit the ExceptionMark destructor with these exceptions pending. Can we determine what action results in the VirtualMachineError being thrown (I know it is due to CodeCache exhaustion but what initialization activity is trigerring the compilation that leads to this)?
23-09-2014

Key info in the log: Event: 3.412 Thread 0x00000000022fb000 Exception <a 'java/lang/VirtualMachineError': out of space in CodeCache for method handle intrinsic> (0x00000000ec092da0) thrown at [/HUDSON/workspace/8-2-build-linux-amd64/jdk8u40/1504/hotspot/src/share/vm/classfile/systemDictionary.cpp, line 2284] Event: 3.412 Thread 0x00000000022fb000 Exception <a 'java/lang/NoSuchMethodError': java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/MemberName;)Ljava/lang/Object;> (0x00000000ec093100) thrown at [/HUDSON/workspace/8-2-build-linu
23-09-2014