JDK-6361259 : Java 1.6 MonitorExit clears exception thrown in native code
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_nevada
  • CPU: x86
  • Submitted: 2005-12-09
  • Updated: 2018-02-23
  • Resolved: 2005-12-30
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 6
6 b66Fixed
Related Reports
Relates :  
JDK-6364623 - JNI specification may need to be corrected.
Relates :  
JDK-6369565 - JVM is crashing when it is not able to determine current working directory
Description
Calling MonitorExit after ThrowNew has the side effect of clearing the exception just thrown.  This behavior does not match java 1.5.  To reproduce using the attached files (a small test case):

javac Test6.java
javah Test6
cc -G -I/usr/j2se/include -I/usr/j2se/include/solaris Test6.c -o libtest6.so
LD_LIBRARY_PATH=. java Test6

Switching the order of these lines
        (*env)->ThrowNew(env, jxc, "error");
        (*env)->MonitorExit(env, jc);
in Test6.c, or reverting to Java 1.5 causes the exception stack trace to print on the console as expected.

The version of Java was obtained from /net/koori.sfbay/onestop/jdk/6/promoted/latest/bundles/solaris-i586/pkgarchive
Dec 8, 2005
Comments
EVALUATION Yes the Spec. needs to be fixed at http://java.sun.com/j2se/1.3/docs/guide/jni/spec/design.doc.html#770. and also thanks!!!! for the really concise but descriptive test cases, made my life a lot easier.
15-12-2005
EVALUATION Please see http://java.sun.com/docs/books/jni/html/design.html#2193. The spec quoted in the previous evaluation comment is incorrect and should be fixed. The attached files Test7.java and Test7.c illustrate why. For example, in Test7.c for (i = 0; i < n; ++i) { (*env)->CallVoidMethod(env, obj, jm, s, i); if ((*env)->ExceptionCheck(env)) { (*env)->MonitorExit(env, jc); return; } } failing to call MonitorExit in the exception case hangs the application; the second thread in Test7.java never gets to run. However, including the MonitorExit call thwarts the exception handler of the first thread in Test7.java.
15-12-2005
EVALUATION JNI spec..... http://java.sun.com/j2se/1.3/docs/guide/jni/spec/design.doc.html#770 "Exception Handling There are two ways to handle an exception in native code: * The native method can choose to return immediately, causing the exception to be thrown in the Java code that initiated the native method call. * The native code can clear the exception by calling ExceptionClear(), and then execute its own exception-handling code. After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). The ExceptionDescribe() function prints a debugging message about the pending exception." There has been discussions about this matter, and depends on the VM implementation, but we should follow the JNI spec.
14-12-2005
EVALUATION The JNI Programmer's Guide and Specification (by Sheng Liang, in Sun's Java Series), section 11.8.2 Java Virtual Machine Exceptions gives the "... complete list of JNI functions that can be called safely when there is a pending exception." The list includes MonitorExit.
14-12-2005
EVALUATION While fixing 6253381, the exception preservation line was inadvertently removed. Need to reinstate the preservation of the exception oop before entering the VM. Not required to backport this fix to tiger updates, the code is correct there. This bug will be fixed, however its a bad idea to make a JNI call after an exception has been thrown, this should be avoided in the application code.
14-12-2005