JDK-4755938 : fatal("PreserveExceptionMark destructor expects no pending exceptions")
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-10-01
  • Updated: 2002-11-13
  • Resolved: 2002-11-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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed 
mode)
#
# Error ID: 5052455345525645255843455054494F4E0E435050001B
#
# Problematic Thread: prio=5 tid=0x0F26EDB8 nid=0x4e8 
runnable 
#

--------------------------------------------------------------

The IDE runs a Tomcat in the JPDA debugging mode. The IDE's debugger is attached to this server. 

Steps to reproduce:
1. Start debug for servlet.
2. Quikly press reload in browser 10-15 times.

Result:
IllegalStateException occured, tomcta crashed, following 
output to host_name:11555 tab (output for W2k):

java.lang.IllegalStateException: Current state = FLUSHED, 
new state = CODING_END
        at 
java.nio.charset.CharsetEncoder.throwIllegalStateException
(CharsetEncoder.java:933)
        at java.nio.charset.CharsetEncoder.encode
(CharsetEncoder.java:529)
        at 
sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar
(StreamEncoder.java:356)
        at sun.nio.cs.StreamEncoder$CharsetSE.implClose
(StreamEncoder.java:413)
        at sun.nio.cs.StreamEncoder.close
(StreamEncoder.java:158)
        at java.io.OutputStreamWriter.close
(OutputStreamWriter.java:222)
        at java.io.PrintWriter.close(PrintWriter.java:137)
        at 
org.apache.catalina.connector.ResponseBase.finishResponse
(ResponseBase.java:482)
        at 
org.apache.catalina.connector.HttpResponseBase.finishRespon
se(HttpResponseBase.java:229)
        at 
org.apache.catalina.connector.http.HttpResponseImpl.finishR
esponse(HttpResponseImpl.java:288)
        at 
org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1038)
        at 
org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1106)
        at java.lang.Thread.run(Thread.java:536)
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed 
mode)
#
# Error ID: 5052455345525645255843455054494F4E0E435050001B
#
# Problematic Thread: prio=5 tid=0x0F26EDB8 nid=0x4e8 
runnable 
#


Well reproduced with under RH Linux 7.2 & W2K with Sun One 
Studio 4 update 1 (build 020812).



Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004

EVALUATION ###@###.### 2002-10-23 A JavaThread is in a JVM/DI RawMonitorWait() call because it is trying to post a THREAD_START event. While it is waiting, another thread sets a pending exception which is not expected. It appears that this pending exception can arrive while the thread is in the raw_wait() call which results in a JVMDI_ERROR_INTERNAL and it can arrive after the check for a pending exception but before the PreserveExceptionMark object is destroyed which causes the fatal() call. The big questions right now are who is throwing the exception and why are they throwing it? ###@###.### 2002-10-23 (update) The VMThread is throwing the exception in response to a request from either JVM/DI StopThread() or JVM_StopThread(). All of the JVM/DI RawMonitor routines setup a PreserveExceptionMark object and call JvmdiInternal::catch_exception() which does two things: - it catches an abnormal result from a underlying ObjectMonitor operation - it checks for a pending exception; if one occurs it is cleared and JVMDI_ERROR_INTERNAL is returned The last part is very strange and I can find no basis for it in the JVM/DI spec. I tracked the code down to the original implementation of JVM/DI in 1999. There is no explanation in the code or in the delta comments.
11-06-2004

PUBLIC COMMENTS .
10-06-2004

SUGGESTED FIX ###@###.### 2002-10-24 See attached 4693620-4755938-webrev.tar file for the pre-code review version of the changes.
24-10-2002