JDK-6317365 : Regresssion: com/sun/image/codec/jpeg/JPEGMultithread.java fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 5.0u7,6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-29
  • Updated: 2011-01-19
  • Resolved: 2005-09-19
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.
JDK 6
6 b53Fixed
Related Reports
Duplicate :  
JDK-6382189 - REGRESSION:JPEGMultithread.java is passing with 1.5.0_06-b05 but failing with 1.5.0_07-b01
Relates :  
JDK-6924778 - com/sun/image/codec/jpeg/JPEGMultithread.java test failed against 5u23HSXDrop
Relates :  
JDK-6899483 - JPEGMultithread.java test failed just against jdk 5.0 with HS 16 in nightly build
Relates :  
JDK-2126497 - -Xcheck:jni JNI call made with exception pending should be a warning
Description
JDK        	    : Fails On:  Mustang b46 and later
Platform[s]         : Fails On:  all platforms
Failing Test [s]    : com/sun/image/codec/jpeg/JPEGMultithread.java

    Test source location:
    =====================
/net/cady/export/jdk1.6.0/latest/ws/j2se/test/com/sun/image/codec/jpeg/JPEGMultithread.java

    jtr file location:
    ==================
/net/cady/export6/results/mustang/b49/reg/regression-reg-IA9-2005-08-26-15-41-47-0346/workDir/com/sun/image/codec/jpeg/JPEGMultithread.jtr

    How to reproduce:
    ====================
    - Set JAVA_HOME to Mustang b47 solaris-sparc
    - cd /net/cady/export/jdk1.6.0/latest/ws/j2se/test/com/sun/image/codec/jpeg   
    - /net/koori.sfbay/onestop/jct-tools/2.1.6/archive/fcs/binaries/solaris/bin/jtreg -r:/tmp -w:/tmp JPEGMultithread.java

    Test output:
    =============
----------System.out:(4/68)----------
Spawning new thread
Reader 0 done
Spawning new thread
Reader 1 done
----------System.err:(8/575)----------
com.sun.image.codec.jpeg.ImageFormatException: JPEG lib error
        at sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream(Native Method)
        at sun.awt.image.codec.JPEGImageEncoderImpl.encode(JPEGImageEncoderImpl.java:472)
        at sun.awt.image.codec.JPEGImageEncoderImpl.encode(JPEGImageEncoderImpl.java:228)
        at sun.awt.image.codec.JPEGImageEncoderImpl.encode(JPEGImageEncoderImpl.java:235)
        at WriterThread.run(JPEGMultithread.java:88)
        at java.lang.Thread.run(Thread.java:608)
STATUS:Failed.`main' threw exception: com.sun.image.codec.jpeg.ImageFormatException: JPEG lib error
result: Failed. Execution failed: `main' threw exception: com.sun.image.codec.jpeg.ImageFormatException: JPEG lib error
Comments
EVALUATION This problem is caused by changes in JNI behaviour. Starting from b46 native method setting up two exceptions delivers second one to the java layer wheras in previous builds (before b46) the first one reaches the java layer. I have attached the test demonstrating such difference in JNI behaviour. In case of I/O problem the jpeg encoder sets up two different exception in the native code: 1 - IOException realted to I/O problem 2 - ImageFormatException created by error handling procedure but only one appears on the java layer. The jpeg encoder relies on fact that the first exception will be delivered to the java layer, but since b46 the unexpected ImageFormatException will be delivered to the java layer. The proposed solution is to avoid the throwing exception from error handling block if exception related to the error was already thrown.
31-08-2005