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