JDK-4784641 : -Xcheck:jni overly strict in JNI method IsSameObject
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: unknown,1.4.1
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2002-11-26
  • Updated: 2012-10-08
  • Resolved: 2003-01-16
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 Other Other
1.3.1_10 10Fixed 1.4.1_07Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4868162 - "Bad global or local ref passed to JNI" in java.io.InputStreamReader.read()
Relates :  
JDK-4720694 - java apps crash on Solaris 9 Ultra-80 machine by using 1.4.1
Description

Name: pa48320			Date: 11/25/2002

I have received the following crash several times since moving to 1.4.2 build 07:
FATAL ERROR in native method: Bad global or local ref passed to JNI
 at sun.awt.windows.Win32GdiBlitLoops.nativeBlit(Native Method)
 at sun.awt.windows.Win32GdiBlitLoops.Blit(Win32GdiBlitLoops.java
 at sun.java2d.pipe.DrawImage.blitSurfaceData(DrawImage.java
 at sun.java2d.pipe.DrawImage.renderSurfaceData(DrawImage.java
 at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java
 at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java
 at sun.java2d.pipe.DrawImage.copyImage(DrawImage.java
 at sun.java2d.pipe.ValidatePipe.copyImage(ValidatePipe.java
 at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java
 at sun.java2d.SunGraphics2D.drawImage(SunGraphics2D.java
 at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java
 at javax.swing.JComponent.paintDoubleBuffered(JComponent.java
 at javax.swing.JComponent._paintImmediately(JComponent.java
 at javax.swing.JComponent.paintImmediately(JComponent.java
 at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java
 at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java
 at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java
 at java.awt.EventQueue.dispatchEvent(EventQueue.java
 at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
 at java.awt.Dialog$1.run(Dialog.java
 at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java
 at java.awt.EventQueue.dispatchEvent(EventQueue.java
 at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java
 at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java
 at java.awt.EventDispatchThread.run(EventDispatchThread.java

We have a C++ applicaiton that embeds the VM inside so I cannot give you a consice test program. It may be possible that this is due to our use of sun.awt.window.WToolkit.embeddedInit().
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.1_10 1.4.1_07 generic mantis-beta FIXED IN: 1.3.1_10 1.4.1_07 mantis-beta INTEGRATED IN: 1.3.1_10 1.4.1_07 mantis-b13 mantis-beta
14-06-2004
EVALUATION Based on the prevalence of java2d in the stack trace, reassigning to java2d. ###@###.### 2002-11-25 Here's some information from the evaluation of 4720694: java apps crash on Solaris 9 Ultra-80 machine by using 1.4.1 The crash with the stack trace above first appeared in 1.4.2 build 07 (caused by the new code for the Region and Xor changes). It can be reproduced on Solaris single or multiple cpu machine (i.e, on my Solaris 8 US60 with disabled DGA), and on Windows. The problem is not specific to the test case in the description, it can be seen when running SwingSet2 with -Xcheck:jni as well. In both cases (windows and solaris) the offending call is env->IsSameObject(env, clip, [w/x]sdo->lastclip) in Win32SD_InitDC and X11SD_InitClip respectively. Looks like the lastclip (which is a global weak reference) is the problem. Jni reports the same error when I tried to create a new local reference out of (non-null, btw) lastclip, or when IsSameObject(lastclip, NULL) is called. It's not clear yet what exactly the vm is complaining about. The lastclip at the time of the failure contains the correct value, returned by NewWeakGlobalRef when lastclip was set, so the at least the value of lastclip is not smashed. When I've replaced WeakGlobalReferences with GlobalReferences, the problem went away. Since the usage pattern didn't change with this 'fix', and we use those weak references only for comparison with IsSameObject() (that is, we don't even get the object from them - only create, compare and delete), I suspect that this might be a vm issue. Also note, that the crash reproducible on Solaris and Windows. Based on this information, I'm reassigning the bug to vm team. They could close it as a duplicate of 4720694, or keep it as a holder for GlobalWeakReference issue, because 4720694 initially was about a different problem. ###@###.### 2002-12-04 ###@###.### 2002-12-06 With -Xcheck:jni, the validation of arguments for IsSameObject is overly strict -- NULL objects are rejected (as they would be for any other JNI call). IsSameObject needs to be a special case.
11-06-2004
WORK AROUND Do not run the app with -Xcheck:jni This parameter is non-standard, and is intended to be used for debugging purposes. ###@###.### 2002-12-04
04-12-2002