JDK-4518124 : native font code makes JNI method invocation in scope of GetStringCritical
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8,solaris_9
  • CPU: sparc
  • Submitted: 2001-10-23
  • Updated: 2002-02-21
  • Resolved: 2002-02-21
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
1.4.1 hopperFixed
Related Reports
Duplicate :  
Relates :  
Description
On merlin (jdk1.4) beta 3 on Solaris native code in the font initialisation
logic is violating the JNI spec.
Executing apps such as demo/jfc/Font2DTest while passing the non-standard
-Xcheck:jni option shows that the JRE is making a Java upcall in the scope
of a GetStringCritical :-

---------------------------
FATAL ERROR in native method: Calling other JNI functions in the scope
of Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical
        at sun.awt.font.NativeFontWrapper.registerFonts(Native Method)
        - locked <f621b1c0> (a java.lang.Class)
        at
sun.java2d.SunGraphicsEnvironment.addPathFonts(SunGraphicsEnvironment.java:712)
        at
sun.java2d.SunGraphicsEnvironment.registerFonts(SunGraphicsEnvironment.java:563)
        at
sun.java2d.SunGraphicsEnvironment.access$000(SunGraphicsEnvironment.java:60)
        at
sun.java2d.SunGraphicsEnvironment$2.run(SunGraphicsEnvironment.java:213)
        at java.security.AccessController.doPrivileged(Native Method)
        at
sun.java2d.SunGraphicsEnvironment.loadFonts(SunGraphicsEnvironment.java:207)
        - locked <f2807d68> (a sun.awt.X11GraphicsEnvironment)
        at
sun.java2d.SunGraphicsEnvironment.mapFamilyName(SunGraphicsEnvironment.java:405)
        at java.awt.Font.initializeFont(Font.java:276)
        at java.awt.Font.<init>(Font.java:308)


---------------------------

This doesn't cause a problem in normal operation but can make it more
difficult to identify similar JNI errors which may occur elsewhere as this one
prevents others being reached whilst running with the -Xcheck:jni option.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper
14-06-2004

PUBLIC COMMENTS On merlin (jdk1.4) beta 3 on Solaris the native font initialisation code is making a Java upcall when it has a lock. This is extremely unlikely to cause a problem in apps but can make debugging JNI usage more difficult.
10-06-2004

EVALUATION The problem could occur on Solaris and Linux but not win32 as the conditions that cause the upcall never exist on windows. A small C++ string buffer class is used to encapsulate a Java string object which in this cases holds the unicode encoded name of a font file. The font code has long used this utility class for this purpose. As it happens that class (JStringBuffer) uses GetStringCritical in its constructor and ReleaseStringCritical in its destructor. This behaviour isn't apparent to users of the class. Whilst this stack allocated C++ object is in scope there is a JNI call to get the element at the nth position of a Vector object. Since this call allocates no objects it will never cause a GC so will not in practice cause any problems in apps. The consequences are just that it limits the usefulness of the -Xcheck:jni option. ###@###.### 2001-10-23 ==============================
23-10-2001

SUGGESTED FIX The simplest fix is probably to make a copy of the filename chars as the JNI upcall is necessary and the memory allocation and copy is not likely to make a perceptible difference in this case. ###@###.### 2001-10-23 ============================
23-10-2001