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.
Improve JNI error checking capabilities to enable customers to diagnose
their own problems.
See evaluation for set of fixes already implemented and set of fixes
remaining.
Comments
CONVERTED DATA
BugTraq+ Release Management Values
COMMIT TO FIX:
tiger
FIXED IN:
tiger
INTEGRATED IN:
tiger
tiger-b16
14-06-2004
EVALUATION
Added for Tiger Release
This bug is being used as a placeholder for improvements to -Xcheck:jni
which allows the user to check for potential problems at debug time
without slowing down performance at run time.
###@###.### 2002-12-03
This is the summary so far:
(a) check for valid JNIEnv* values.
(b) check for JNI calls done while exceptions are pending.
(c) dump the native stack at the time of failure.
(d) diagnostics during JNI_CreateJavaVM, JNI_AttachCurrentThread.
(e) argument checking on native calls to Java methods.
(f) Get/Release calls are paired.
(g) check for JNI calls between GetCritical/ReleaseCritical.
(h) JNI handles need to be validated, not just the objects.
###@###.### 2003-02-04
As of mantis-beta,
(a) is done, see 4801018.
(b) is done, see 4781315, and undone, see 4808145.
Exceptions are required to be checked for some JNI methods in the
standard code paths (not Xcheck), see 4808118.
(c) needs to be done.
(d) needs to be done.
(e) needs to be considered. Many important cases are already covered.
Remaining cases need to be examined.
(f) need to be done.
(g) is done, see 4801031.
(h) is done, see 4801018.
---
(b) is putback again, by following the JNI1.2 specification to allow
more legal JNI functions that can be called with a pending exception.
(c) will be tracked with a different bug later. The native stack walking
is already part of the fatal error handling.
(f) is tracked with 4791581.
###@###.### 2003-08-08
08-08-2003
SUGGESTED FIX
One potential fix we could add would be to reduce the risk of crashes
due to old JNIEnv* values. These are currently calculated from thread
values.
It is worth considering having a table of threads, so that we have
a way to check for invalid threads as well, since threads are frequently
passed in as JNI/JVM arguments that are no longer valid. For instance
we have thread_from_jni_environment which checks is_terminated in
a thread, where that memory may have been recycled. This could be
a way to improve jni robustness. If the overhead is high we could
just do this part under -Xcheck:jni.
Fixing this should be considered when fixing 4662919.
###@###.### 2002-09-06
From Mingyao Yang:
Recently we encountered an app that didn't clear the pending exception
in its JNI code before doing another JNI call, which caused a crash
(a delayed one so it's difficult to troubleshoot). So we think one
enhancement to -Xcheck:jni is to make sure there is no pending
exception (except for the few JNI calls that are legal to have a pending
exception). (see also 4738334)
From Hongfeng Shen:
Another improvement in -Xcheck:jni may be that instead of raising
the FatalError currently, we also dump the native stack so that we
can see the offending method right away.
###@###.### 2002-10-07
Customers have been asking for improvements to JNI_CreateJavaVM calls.
Perhaps -Xcheck:jni could provide additional diagnostic information
when this call fails. (Probably also appreciated for JNI_AttachCurrentThread).
This might satisfy requests for additional error value returns to
JNI_CreateJavaVM without changing the API.
###@###.### 2002-12-03
Currently with -Xcheck:jni, the jni handles are not being validated. The
objects refered to by the handles are usually checked, but this is not
the same thing.