JDK-4868162 : "Bad global or local ref passed to JNI" in java.io.InputStreamReader.read()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: unknown
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-05-22
  • Updated: 2003-06-05
  • Resolved: 2003-06-05
Related Reports
Duplicate :  
JDK-4784641 - -Xcheck:jni overly strict in JNI method IsSameObject
Description
###@###.### 2003-05-22

SAP has found the following problem when starting their IPC application
on Windows 2000 with 1.3.1_08 and -Xcheck:jni:

> FATAL ERROR in native method: Bad global or local ref passed to JNI
        at java.io.InputStreamReader.read(InputStreamReader.java:245)
        at java.io.BufferedReader.read1(BufferedReader.java:180)
        at java.io.BufferedReader.read(BufferedReader.java:256)
        - locked <2f278f8> (a java.io.InputStreamReader)
        at com.sap.sxe.socket.server.SocketConnection.work(SocketConnection.java:137)
        at com.sap.sxe.socket.server.Worker.run(Worker.java:107)

The source for the SocketConenction.java class is attached, and there is no SAP JNI
calls anywhere in this. I'm confusded by the fact that a call in the Java IO
libs can produce such a problem, but I haven't found anything in the Java
bug database or on the web.
Comments
WORK AROUND Do not run with -Xcheck:jni ###@###.### 2003-06-05
05-06-2003
EVALUATION This behaviour is very odd since there's no native code in java.io,InputStreamReader. Perhaps thers's a delay between when the JNI check is done and when the problem is reported? Is the problem reproducible in jdk1.4.2 (build 24)? The class was changed significantly during jdk1.4 development. -- iag@sfbay 2003-05-22 Please provide a small encapsulated example which reproduces the problem. The example should contain the source and instrutions to compile and run the test code. -- iag@sfbay 2003-05-23 I'll try to get this from SAP. It will be difficult, tho, to make this a small example, since - as usual - the application is very complex and the Java stack trace doesn't really help us here. ###@###.### 2003-06-05 ---------------------------------- Stacktrace for offending thread (from customers site): jvm!ValidateObject+0x32 jvm!checked_jni_IsSameObject+0x1a jdwp!commonRef_compact+0x35 jdwp!eventHook+0x65 jvm!JvmdiInternal::post_event+0x62 jvm!jvmdi::post_exception_throw_event+0x1d7 jvm!InterpreterRuntime::exception_handler_for_exception+0xf8 ..... The customer is running 'java -Xcheck:jni -Xdebug -Xrunjdwp...'. commonRef_compact is using IsSameObject to check if the jobject is gc'ed or not. In the case that is causing the problem for the customer the jni handle is valid but contains NULL. This is a valid scenario and we should not be trying to validate the object pointed to by the handle. The check jni wrapper for IsSameObject is too strict. If the handles are valid, but contain NULL, then don't attempt to validate the object. Dup of 4784641 ###@###.### 2003-06-05 ---------------------------------------
05-06-2003