JDK-5031504 : 1.4.2_05: 3 JCK tests failing with -Xcheck:jni flag on Linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2_05
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: x86
  • Submitted: 2004-04-14
  • Updated: 2012-10-08
  • Resolved: 2004-06-25
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 JDK 6
1.4.2_06 06Fixed 6Fixed
Description
Ran JCK runtime tests for 1.4.2_05 on RHEL3.0 and quicksilver with the -Xcheck:jni flag.
3 tests fail with this flag, and pass if it's not used.

The same tests fail with 1.4.2 fcs so it's not a Regression.

The 3 failing tests are:

api/javax_swing/plaf/multi/MultiComboBoxUI/index.html#public
api/javax_swing/plaf/multi/MultiColorChooserUI/index.html#public
vm/jni/NewWeakGlobalRef/nwgr001/nwgr00101m1/nwgr00101m1.html

The jtr files are attached.

To reproduce the failures:
- Install the JDK on a linux machine.
- Set path to pick up java
- Set CLASSPATH to /net/latte.ireland/export/home4/jck/JCK-runtime-14a/classes

java -Xcheck:jni javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1 -platform.nativeCodeSupported true

java -Xcheck:jni javasoft.sqe.tests.api.javax.swing.plaf.multi.MultiColorChooserUI.publicTests

java -Xcheck:jni javasoft.sqe.tests.api.javax.swing.plaf.multi.MultiComboBoxUI.publicTests


===========================================================================


javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1 test is still failing for 1.4.2_06b1
(only when -Xcheck:jni flag is used)
bug has been marked as INT for 1.4.2_06

Same error produced :

#section:testExecute
----------messages:(1/483)----------
command: com.sun.jck.lib.ExecJCKTestOtherJVMCmd CLASSPATH=/net/latte/export/home4/jck/JCK-runtime-14a/classes LD_LIBRARY_PAT
H=/net/latte.ireland/export/home4/jck/JCK-runtime-14a/lib/sparc DISPLAY=club:0.0 HOME=/home/sc87771 //export/home/j2sdk1.4.2
_06/bin/java -Xcheck:jni -Djava.awt.headless=false -Xfuture -Djava.security.policy=/net/latte/export/home4/jck/JCK-runtime-1
4a/lib/jck.policy javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1 -platform.nativeCodeSupported true
----------ref:(6/539)----------
FATAL ERROR in native method: Null object passed to NewWeakGlobalRef
        at javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1.nwgr00101m1CheckNULLObj(Native Method)
        at javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1.InitCheckRefs(nwgr00101m1.java:70)
        at javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1.testChecks(nwgr00101m1.java:179)
        at javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1.run(nwgr00101m1.java:241)
        at javasoft.sqe.tests.vm.jni.nwgr001.nwgr00101m1.nwgr00101m1.main(nwgr00101m1.java:245)
----------log:(0/0)----------
result: Failed. unexpected exit code: exit code 6


###@###.### 2004-07-01
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic mustang tiger-rc FIXED IN: 1.4.2_06 mustang tiger-rc INTEGRATED IN: 1.4.2_06 mustang tiger-b59 tiger-rc
31-08-2004
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. ------------------------------------------
31-08-2004
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
13-05-2004