-
Bug
-
Resolution: Fixed
-
P3
-
6u26
-
b100
-
x86
-
linux
FULL PRODUCT VERSION :
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
OS independent
A DESCRIPTION OF THE PROBLEM :
The C code in /sun/font/scalerMethods.c calls the Java method sun.font.Type1Font.readFile() using the wrong JNI invocation method: This void method is invoked using CallObjectMethod. Search for "t1ReadBlockMID" to find the wrong invocation. It is easy to see that a void method is searched using GetMethodID, but then CallObjectMethod instead of CallVoidMethod is used to invoke it.
Since the whole code got rewritten for JDK 7, the bug only affects JDK 6.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We detected the issue with the Maxine VM, the Java VM written in Java from Oracle Labs - since Maxine is completely type safe, it raised an exception with this code.
I don't know a way to reproduce it with HotSpot, because it does not detect this issue even when -Xcheck:jni is used. Adding the necessary checks to the JNI checking of HotSpot would be helpful.
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
OS independent
A DESCRIPTION OF THE PROBLEM :
The C code in /sun/font/scalerMethods.c calls the Java method sun.font.Type1Font.readFile() using the wrong JNI invocation method: This void method is invoked using CallObjectMethod. Search for "t1ReadBlockMID" to find the wrong invocation. It is easy to see that a void method is searched using GetMethodID, but then CallObjectMethod instead of CallVoidMethod is used to invoke it.
Since the whole code got rewritten for JDK 7, the bug only affects JDK 6.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We detected the issue with the Maxine VM, the Java VM written in Java from Oracle Labs - since Maxine is completely type safe, it raised an exception with this code.
I don't know a way to reproduce it with HotSpot, because it does not detect this issue even when -Xcheck:jni is used. Adding the necessary checks to the JNI checking of HotSpot would be helpful.
REPRODUCIBILITY :
This bug can be reproduced always.