Name: ks84122 Date: 02/13/2003
The report from Apple below describes a bug in sun_jpeg_fill_suspended_buffer() that causes a JVM crash. It also mentions the ZipFile problem which is filed as a separate bug(4818580).
Original description:
=====================
1. Use SwingSet2 JFC example. Expand the jar file and recreate it using jar cm0f to get an uncompressed jar.
2. Run the example using the uncompressed jar file.
3. Click on the JEditorPane HTMLDemo icon.
4. Scroll down the page. Click on the first link (Title Page).
5. Crash.
The crash is due to code in src/share/native/sun/awt/image/jpeg/jpegdecoder.c, function sun_jpeg_fill_suspended_buffer() uses size_t paramaters (unsigned integers) for ret, offset, buflen. However, the error code returned from the JNI calls it makes are jints, and return -1 to indicate an error. So this code never indicates an error:
if (ret <= 0) {
/* Silently accept truncated JPEG files */
WARNMS(cinfo, JWRN_JPEG_EOF);
src->inbuf[offset] = (JOCTET) 0xFF;
src->inbuf[offset + 1] = (JOCTET) JPEG_EOI;
ret = 2;
}
The end result is that the return length becomes a very large positive integer and a call to memmove later scribbles all over memory.
ret should be jint type, or cast to an (int) for the test.
Once the abvoe problem is fixed, reading the same JPEG files from an uncompressed jar file give "Premature end of JPEG" warnings. This problem is because ZipFileInputStream's available() method incorrectly returns the full entry size in its available() method, rather than the remaining number of bytes that can be read. In src/share/classes/java/util/zip/ZipFile.java:
public int available() {
return size;
}
should be:
public int available() {
return rem;
}
(Review ID: 181199)
======================================================================