EVALUATION
The test failures appear on Solaris as well as linux.
The following tests have the same failure:
javasoft.sqe.tests.api.javax.swing.plaf.multi.MultiColorChooserUI.publicTests
javasoft.sqe.tests.api.javax.swing.plaf.multi.MultiComboBoxUI.publicTests
[6] os::abort(0x1, 0xfe31b1c4, 0xfe40409e, 0xffbecf48, 0xffbed260, 0xffbed2b8), at 0xfdffb5c0
[7] ReportJNIFatalError(0x3fa68, 0xfe40409e, 0xf72286d0, 0xffbecfb8, 0xf74e0d28, 0x0), at 0xfde13de8
[8] ValidateObject(0x3fa68, 0x8bc54, 0x10002, 0xfb4245f0, 0xf74e0d28, 0x0), at 0xfde37c68
[9] checked_jni_NewLocalRef(0x3fb10, 0x8bc54, 0x1, 0xfb4245f0, 0xf74e0d28, 0x0), at 0xfde16ec0
=>[10] awt_canvas_getFocusOwnerPeer(), line 761 in "canvas.c"
[11] Java_sun_awt_motif_MComponentPeer_restoreFocus(env = 0x3fb10, this = 0xffbed204), line 1481 in "awt_Component.c"
[12] 0xfb40dedc(0xf316d518, 0xb6, 0xffbed284, 0x4, 0xf74e0d28, 0xffbed1a8), at 0xfb40dedb
....
awt_canvas_getFocusOwnerPeer calls NewLocalRef on focusOwnerPeer. focusOwnerPeer
is a weak global ref and as such could be gc'ed at any time. In the case above
focusOwnerPeer has been gc'ed, and althought the handle is valid the object no
longer exists. This is the correct way to handle weak global refs as stated in
the 1.2 jni spec:
"To overcome this inherent limitation, it is recommended that a standard
(strong) local or global reference to the same object be acquired using the
JNI functions NewLocalRef or NewGlobalRef, and that this strong reference be
used to access the intended object. These functions will return NULL if the
object has been freed, and otherwise will return a strong reference (which
will prevent the object from being freed). The new reference should be
explicitly deleted when immediate access to the object is no longer required,
allowing the object to be freed."
I think that checked_jni_NewLocalRef should behave similar to
checked_jni_IsSameObject. That is if the handles are valid, but contain NULL,
then we should not attempt to validate the object.
This tests fails for a different reason:
javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1
[7] ReportJNIFatalError(0x3fab8, 0xfe320767, 0x8, 0x2, 0x1, 0xffbedc94), at 0xfde13de8
[8] NativeReportJNIFatalError(0x3fab8, 0xfe320767, 0x8, 0xffbedb5c, 0xffbedb58, 0xffbedb54), at 0xfde13ee4
[9] checked_jni_NewWeakGlobalRef(0x3fb60, 0x0, 0x3fab8, 0x0, 0x0, 0x0), at 0xfde35a80
=>[10] Java_javasoft_sqe_tests_vm_jni_nwgr001_nwgr00101m1_nwgr00101m1_nwgr00101m1CheckNULLObj(env = 0x3fb60, obj = 0xffbedd9c), line 38 in "nwgr00101m1.c"
[11] 0xfb40dedc(0xf3020a90, 0xb6, 0xffbede24, 0x4, 0xb8, 0xffbedd38), at 0xfb40dedb
...
I am not sure about the validity of this test. Basically we try to create a new
weak global ref with NULL and expect the result to also be NULL. From the 1.2
jni spec:
"Creates a new weak global reference. Returns NULL if obj refers to null,
or if the VM runs out of memory."
I think what this test should be doing is using a valid handle to NULL and not
NULL itself.
###@###.### 2004-04-15
------------------------------------------
###@###.### 2004-07-01
There are two problems here.
(1) There is a real problem with JNI check, which is fixed.
(2) There is a real problem with the test, as described above.
I have filed a new bug (5070592) indicating that test nwgr00101m1
is faulty. This test bug remains, which is why the test failed again.
------------------------------------------
|
SUGGESTED FIX
--- jniCheck.cpp
*** 533,543 ****
--- 533,545 ----
JNI_ENTRY_CHECKED(jobject,
checked_jni_NewGlobalRef(JNIEnv *env,
jobject lobj))
functionEnter(thr);
IN_VM(
+ if (lobj != NULL && ValidateHandle(thr, lobj) != NULL) {
ValidateObject(thr, lobj);
+ }
)
jobject result = UNCHECKED()->NewGlobalRef(env,lobj);
functionExit(env);
return result;
JNI_END
*** 596,606 ****
--- 598,610 ----
JNI_ENTRY_CHECKED(jobject,
checked_jni_NewLocalRef(JNIEnv *env,
jobject ref))
functionEnter(thr);
IN_VM(
+ if (ref != NULL && ValidateHandle(thr, ref) != NULL) {
ValidateObject(thr, ref);
+ }
)
jobject result = UNCHECKED()->NewLocalRef(env, ref);
functionExit(env);
return result;
JNI_END
###@###.### 2004-05-13
|