United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-5031504 1.4.2_05: 3 JCK tests failing with -Xcheck:jni flag on Linux
JDK-5031504 : 1.4.2_05: 3 JCK tests failing with -Xcheck:jni flag on Linux

Details
Type:
Bug
Submit Date:
2004-04-14
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2004-06-25
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_05
Fixed Versions:
1.4.2_06 (06)

Related Reports
Backport:
Backport:

Sub Tasks

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
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
                                     
2004-05-13
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.
------------------------------------------




                                     
2004-08-31
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


                                     
2004-08-31



Hardware and Software, Engineered to Work Together