247604 - The bottom line of PNG not displayed when the end of the image data and the zlib's CRC are in different IDAT chunks.

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[kisaragi_24]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040618 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040618 Firefox/0.8.0+

This sample is a simple box image, however, Mozilla does not display the bottom
line.
Maybe it is because of the reason written in the summary:

+---------IDAT---------+---------IDAT---------+
|...data, data, dataend|  Zlib's CRC and end  |
+---------IDAT---------+---------IDAT---------+

Reproducible: Always
Steps to Reproduce:

Comment 1

[kisaragi_24]

Attachment: Sample image.

Sample image.

Comment 2

[Glenn Randers-Pehrson]

When I use mozilla configured with libmng providing PNG support, the bottom
line of the image is shown properly.  But if libpng provides PNG support, then
I can confirm that the bottom line is missing.

Comment 3

[Glenn Randers-Pehrson]

The bug doesn't seem to be in libpng.  ImageMagick's "display" and
both libpng's contrib/gregbook/rpng-x and rpng2-x display the complete
image.  Rpng2-x uses the same progressive reading method that mozilla uses.

Comment 4

[tor]

Instrumenting the png decoder, we're not getting a row callback for the last row.

Comment 5

[Glenn Randers-Pehrson]

Right.  That would probably be the fault of png_process_IDAT_data() in pngpread.c
which happens to be troublesome, hard-to-follow code that has had bugs
in the past.

Comment 6

[kisaragi_24]

Attachment: Another sample.

The bottom line of this second sample is also not displayed which only the CRC
4 bytes of zlib-compressed-data are in another IDAT chunk. This bug seems to
occur when any bytes of zllb's CRC 4 bytes are separated from its data field,
not relating to BFINAL.

Comment 7

[Glenn Randers-Pehrson]

Attachment: patch for libpng pngpread (bugzilla 247604)

This patch appears to correct the problem.  libpng's progressive reading
function was incorrectly finding too much data under circumstances where
the expected pixel data had all been aquired but there was some remaining
zlib data still to be processed.

Comment 8

[Glenn Randers-Pehrson]

The patch for libpng's pngpread was applied to libpng version 1.2.6, so
upgrading to 1.2.6 will fix this bug.

Glenn

Comment 9

[Glenn Randers-Pehrson]

Although libpng-1.2.7 has been checked in to trunk, I'm still seeing this bug
with Firefox (rv:1.7.3) Gecko/20041027 Firefox/1.0RC1 (amano).  I assume another
checkin of bug #261922, to aviary, is required.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

All testcases WFM on the latest trunk (at least, I see the bottoms of all the
boxes), and I think it's safe to say that this isn't going to be fixed on the
1.0.x branch. Maybe a VERIFIED FIXED is in order?

Comment 11

[Glenn Randers-Pehrson]

Setting blocking flags to "?" for FF 1.0.8 and Moz 1.7.13.  If some authority
answers with "-" then we can close this bug as FIXED (and imply wontfix these
earlier branches).

Comment 12

[Glenn Randers-Pehrson]

Since there seems to be no interest in fixing the 1.7 branch, I'm marking this bug FIXED, and by implication, WONTFIX the 1.7 branch.