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.
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.