JDK-7153693 : Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* Unbreakable Kernel x64
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u33,7u4
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2012-03-14
  • Updated: 2012-07-31
  • Resolved: 2012-07-31
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 7 JDK 8
7u6 b17Fixed 8Fixed
Description
Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* Unbreakable Kernel x64
on JDK 7 u04 b13 
See more in comments

Comments
SUGGESTED FIX http://cr.openjdk.java.net/~bae/7153693/7u6/webrev.00/
15-06-2012

EVALUATION This problem is caused by incorrect usage of memcpy routine in sun_jpeg_fill_suspended_buffer: The linux man for memcpy says: "The memory areas must not overlap. Use memmove(3) if the memory areas do overlap." This is exactly the case of the sun_jpeg_fill_suspended_buffer, were we move overlapped memory areas under some conditions. Some linux systems are tolerant to the problem, but OEL 6.* Unbreakable Kernel x64 is not, so the problem is visible there, and manifests in occasional failures during decoding of progressive jpegs. Suggested fix is just use memmove instead of memcpy.
09-06-2012

EVALUATION This problem is caused by a failure in Toolkit image decoder: for some reasons, the jpeg decoder fails to read a certain file multicolor.jpg. The problem happens occasionally and seems to be caused by a peculiarity of file i/o buffering on the OEL6 system. Simplified testcase either fails with the exception listed in the description, or reads the image successfully. Also, if image data are explicitly buffered in a memory buffer, the reading success always. Note that this is not a regression: the jdk6 demonstrates the same behavior. So the problematic code seems to be present in jdk for a long period of time.
21-03-2012