Hm... I commented on dev-list on this issue already in using classlib
launcher in DRLVM.
JNI specification explicitly states that:
---------------------------------------------------------------------
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().
---------------------------------------------------------------------
See [1] at the end of Exception Handling section (and the end of the page).
So, it's nice that VM won't crash if entered JNI function in exception
state, but it is obviously resposibility of native code (launcher in our
case) to check pending exceptions and process them as necessary _before_
calling into JNI.
Regards,
Pavel Pervov.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/design.html#wp770
On 7/20/06, Geir Magnusson Jr (JIRA) <[EMAIL PROTECTED]> wrote:
[ http://issues.apache.org/jira/browse/HARMONY-927?page=all ]
Geir Magnusson Jr closed HARMONY-927.
-------------------------------------
> DRLVM's DestroyVM needs to be more robust
> -----------------------------------------
>
> Key: HARMONY-927
> URL: http://issues.apache.org/jira/browse/HARMONY-927
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Reporter: Andrey Chernyshev
> Assigned To: Geir Magnusson Jr
> Attachments: destroy_vm.patch
>
>
> drlvm should handle the fact that an exception already exists on
entering DestroyJavaVM, and clear it before trying to resolve the VMStart
class.
> Here is a small patch that adds a simple check into the shutdown method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
