JDK-4528643 : Native JPEG code makes JNI calls in scope of GetPrimitiveArrayCritical
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.imageio
  • Affected Version: 1.4.0,1.4.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux,windows_xp
  • CPU: generic,x86
  • Submitted: 2001-11-17
  • Updated: 2011-05-26
  • Resolved: 2006-05-02
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 JDK 6
1.4.2_33Fixed 6 b83Fixed
Related Reports
Duplicate :  
JDK-7011615 - JRockit JDK Simplification - Backport fix for sun bug 4528643 (in imageioJPEG.c) to 1.4.2 and 1.5.0
Duplicate :  
JDK-6339169 - ImageReader.read() triggers JNI warning messages
Duplicate :  
JDK-4737496 - JPEGImageWriter causes FatalError(1.4) & warning msgs(1.4.1-rc) with -Xcheck:jni
Relates :  
JDK-4518124 - native font code makes JNI method invocation in scope of GetStringCritical
Description
Certain methods in imageioJPEG.c (the glue code between the IJG native JPEG
libraries and the Image I/O API) such as readImageHeader(), readImage(),
writeImageHeader(), and writeImage() make JNI calls in the scope of
Get/ReleasePrimitiveArrayCritical.  Most Java upcalls in the file have been
correctly surrounded with RELEASE/GET_ARRAYS macros, but a few cases fell
through the cracks.

Running any application that reads or writes JPEG images with the non-standard
-Xcheck:jni flag causes the following error (or something similar):

FATAL ERROR in native method: Calling other JNI functions in the scope of Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.readImageHeader(Native Method)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.readNativeHeader(JPEGImageReader.java:545)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.checkTablesOnly(JPEGImageReader.java:300)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.gotoImage(JPEGImageReader.java:422)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.readHeader(JPEGImageReader.java:538)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.readInternal(JPEGImageReader.java:871)
	at com.sun.imageio.plugins.jpeg.JPEGImageReader.read(JPEGImageReader.java:855)
	at javax.imageio.ImageIO.read(ImageIO.java:1317)
	at javax.imageio.ImageIO.read(ImageIO.java:1241)
	at Test.<init>(Test.java:29)
	at Test.main(Test.java:40)

These problem areas are unlikely to cause problems, but we should try to
conform to the JNI specs, which mandate that no JNI upcalls be made inside
of a critical section.
###@###.### 2001-11-16
Comments
EVALUATION The reason of -Xcheck:jni warnings in readImageHeader() method was invocation of the setImageData() method in the critical section. Numerous warnings in the writeImage() method were caused by handling encoding tables (that requires number of jni calls) inside critical section. However, we can get output buffer array later, after completion of encoding tables processing.
20-04-2006
SUGGESTED FIX Unfortunately the line numbers above are no longer accurate, so we should probably look through the code for possible problem areas.
13-04-2006
EVALUATION We have an important demo app that loads a ton of JPEG files and triggers this bug, so when -Xcheck:jni is enabled it makes it very difficult to see if there are any JNI-related issues other than the one reported here. We should fix this for Mustang if possible. The most reproducible case is the one reported in the description field: in imageioJPEG.c, in the readImageHeader() method we call read_icc_profile() within a GET/RELEASE pair, which in turn calls into various CMM functions that make JNI calls. For each one of those JNI calls another -Xcheck:jni warning is emitted which causes a lot of confusing spew to the console. We should be able to fix this by calling RELEASE_ARRAYS() before the CallVoidMethod(setImageDataID). It should be easy to reproduce this bug by reading a JPEG image with an embedded color profile.
13-04-2006
PUBLIC COMMENTS The native JPEG code for Image I/O is making a number of JNI method calls when it has a lock (inside of a Get/ReleasePrimitiveArrayCritical pair). This is unlikely to cause problems in any application, but the offending code should be reworked so we conform to the JNI specification.
24-08-2004
EVALUATION We should make sure all Java upcalls in imageioJPEG.c are surrounded with a RELEASE/GET_ARRAYS pair (as enumerated in the suggested fix). We can use the non-standard -Xcheck:jni flag to verify that all offending code has been properly reorganized. ###@###.### 2001-11-16
16-11-2001
SUGGESTED FIX Ensure all JNI method calls in imageioJPEG.c are appropriately wrapped in a RELEASE/GET_ARRAYS macro pair. The method calls on the following lines in imageioJPEG.c are suspect: 1608, 1843, 1848, 1930, 2320-2344, and 2486-2604. ###@###.### 2001-11-16
16-11-2001