|
Quick Lists
|
|
Bug ID:
|
4528643
|
|
Votes
|
1
|
|
Synopsis
|
Native JPEG code makes JNI calls in scope of GetPrimitiveArrayCritical
|
|
Category
|
java:imageio
|
|
Reported Against
|
1.4
, 1.4.2
, merlin-beta3
|
|
Release Fixed
|
mustang(b83)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6339169
,
4518124
,
4737496
|
|
Submit Date
|
17-NOV-2001
|
|
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.
xxxxx@xxxxx 2001-11-16
|
|
Work Around
|
N/A
|
|
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.
xxxxx@xxxxx 2001-11-16
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.
Posted Date : 2006-04-13 06:31:38.0
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.
Posted Date : 2006-04-20 09:42:38.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |