JDK-6730115 : Fastdebug VM crashes with "ExceptionMark destructor expects no pending exceptions" error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-07-25
  • Updated: 2019-01-14
  • Resolved: 2013-12-31
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
8u192Fixed 9 b02Fixed
Related Reports
Duplicate :  
JDK-8199930 - fatal error: ExceptionMark destructor expects no pending exceptions
Relates :  
JDK-6425580 - JVM crashes on failed 'read' call: Internal Error in exceptions.cpp, 308
Description
Fastdebug VM crashes with "ExceptionMark destructor expects no pending exceptions" error.
See comments.
Comments
The AttachListener::init() method appears to be incorrectly written: It starts: void AttachListener::init() { EXCEPTION_MARK; klassOop k = SystemDictionary::resolve_or_fail(vmSymbolHandles::java_lang_Thread(), true, CHECK); ... and proceeds to use several Java upcalls that use the CHECK macro. But the CHECK checks for a pending exception and returns, which means that if an exception occurs we will defintely hit the ExceptionMark destructor with an exception pending. This code seems to be confused about how it should handle Java-level exceptions: - the ExceptionMark says they should be handled locally - the CHECK macro says the caller should handle them This is perhaps related to whether this code expects to be called during VM initialization or not. For example, a later part of the code does: { MutexLocker mu(Threads_lock); JavaThread* listener_thread = new JavaThread(&attach_listener_thread_entry); // Check that thread and osthread were created if (listener_thread == NULL || listener_thread->osthread() == NULL) { vm_exit_during_initialization("java.lang.OutOfMemoryError", "unable to create new native thread"); } but with lazy AttachListener initialization this may not occur during VM initialization at all. In the current case this code is being called in response to a SIGBREAK that is being processed by the signal thread. It is unclear whether failure to start the attach listener should be a fatal VM error. If it is then this is just a clumsy way of reporting it.
21-03-2018