crash loading very thin (e.g. one-pixel-wide) PNG images

VERIFIED FIXED in mozilla0.8

Status

()

VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: vectro, Assigned: tor)

Tracking

({crash})

Trunk
mozilla0.8
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i686; en-US; 0.7) Gecko/20010105
BuildID:    20011010517

When the image is loaded, either via an IMG tag, style sheets, or typing it
directly into the URL bar, Mozilla crashes.

Converting the image into JPEG, mozilla displays it fine.

Reproducible: Always
Steps to Reproduce:
Enter image URL into location bar

Actual Results:  Mozilla crashes, printing on the console:

moo!moo!moo!libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type
libpng warning: Ignoring bad adaptive filter type

(note that this is the EXACT number of times it prints it.)

Expected Results:  displayed the image

An offending image, uuencoded:



begin 664 gradient.png
MB5!.1PT*&@H````-24A$4@````(```(5"`(```$#GXGO````!&=!34$``+&/
M"_QA!0````EP2%ES```+$@``"Q(!TMU^_`````=T24U%!]$!#P,+.E<+XNP`
M``+%241!5'C:I5;;EILP$-,HWLO_?VFW/=L$$X_Z8!ML,&R2/G`,S$VCD0U(
M]T@`E$0I$0`!T!T$$LWS\S5.2--?WN>Y^#N%F1?W$JL<:Z*[$[*<I^04YNSC
MV4[E.%>B)-+3DJ=BD434M;$#H+DUN$5#P>[WQ4<2W9P.T4H]@)2,9C4^E7MB
MY2*M=<R84B*@A8O;'/D9WIHZ=PJ)3*G#!"N]E#BA<-5P(8E6>RMV>J*[+_G=
M[SF^K",NNADH^UG3AR0FYIPK%R$_FY6U^MK"1;VR_XJI7F;6804J)K1^D&;^
M_?[F!0;%*V/<YB\]ECE>O*^UNS?U[QQ=+["M?Z^+RGWUJ7IL9]?6I6]FV]BV
MW&0];KAJXD?]4-SUVL7KWO5'^-ZG>4[L[>O,JV_H[64_M/VT[]K]<72M^<?8
M1E>MD35D2VRKI<77SW/-GAACA#3S]]<7+S!^?'PP7"Z<IFG3SPB_=_6K%E>-
MC'C$4*.C]V9&G7$CZV9/<J\%TSGOYH>:R#K4#[,9[[NL4>SW51OK63<\T_%!
M[;:'<_L)=J73.F=ZS.<B'IKK41["BX;&\S.!,'\(S[`N?HXWG>V]D',<Q!_M
MCU5[?NJ'<H9)LG2/]>A_9@F2FB?`CVS/IS:S-4MP]UR!NT)K]4$]%BP.>Q:$
M&_CV^9%28HQ1$J_7Z_O[NTESG*8P7V]QFG#]\TLIFN9;G*8PW6Z2@ID5VI_E
MTP_[$]*@/V6RY!<]S_RKG@&FY[/("-D^61DQR4-;5^\1@%("&(Q"_BP<X=R\
M-%6;:8SEM$W*`0^2U,5I5%;+07'6W[BLU;DG:?WDGQ*B5\;_Z@[?TKJ-4_Y9
M.*MN<,)3.<XP9O!YV]B3@`E<?V$>BGODY<%BGO]/!$M#O022,NQM$$AX.=[Q
M/R`>C0N)_LH9$DRO?!$8@*!7<.:/QO.#`QS69;&'.`.(Y=S]!XV!6$F:;T\<
,`````$E%3D2N0F""
`
end

Comment 1

18 years ago
Created attachment 22589 [details]
attachment as PNG

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

18 years ago
Verfying report. Clicking link to attachment crashed moz twice in a row, with
described console output. Linux 2001011306

NC4.75 loads it OK. 

On a non-debug:
#0  0x412549db in NSGetModule () from /home/dark/package/components/libnspng.so
#1  0x4124efac in NSGetModule () from /home/dark/package/components/libnspng.so
#2  0x4124eeaa in NSGetModule () from /home/dark/package/components/libnspng.so
#3  0x4124edde in NSGetModule () from /home/dark/package/components/libnspng.so
#4  0x4124e146 in NSGetModule () from /home/dark/package/components/libnspng.so
#5  0x4124e0c7 in NSGetModule () from /home/dark/package/components/libnspng.so
#6  0x4124c0f0 in NSGetModule () from /home/dark/package/components/libnspng.so
#7  0x4124c80f in NSGetModule () from /home/dark/package/components/libnspng.so
#8  0x40034050 in IL_StreamWrite () from /home/dark/package/libgkgfx.so
#9  0x40031507 in NetReaderImpl::Write () from /home/dark/package/libgkgfx.so
#10 0x40029cd1 in ImageConsumer::OnDataAvailable ()
   from /home/dark/package/libgkgfx.so
#11 0x40b5deb3 in NSGetModule ()
   from /home/dark/package/components/libgklayout.so
#12 0x409ea8df in NSGetModule ()
   from /home/dark/package/components/liburiloader.so
#13 0x4090fd51 in NSGetModule () from /home/dark/package/components/libnecko.so
#14 0x408eff43 in NSGetModule () from /home/dark/package/components/libnecko.so
#15 0x408ea7ed in NSGetModule () from /home/dark/package/components/libnecko.so
#16 0x4090edde in NSGetModule () from /home/dark/package/components/libnecko.so
#17 0x408cba23 in NSGetModule () from /home/dark/package/components/libnecko.so
#18 0x408cb2a4 in NSGetModule () from /home/dark/package/components/libnecko.so
#19 0x400c6403 in PL_HandleEvent () from /home/dark/package/libxpcom.so
#20 0x400c6326 in PL_ProcessPendingEvents ()
   from /home/dark/package/libxpcom.so
#21 0x400c707d in nsEventQueueImpl::ProcessPendingEvents ()
---Type <return> to continue, or q <return> to quit---
   from /home/dark/package/libxpcom.so
#22 0x406e2d9f in NSGetModule ()
   from /home/dark/package/components/libwidget_gtk.so
#23 0x406e2b5d in NSGetModule ()
   from /home/dark/package/components/libwidget_gtk.so
#24 0x405deaca in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#25 0x405e0186 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#26 0x405e0751 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#27 0x405e08f1 in g_main_run () from /usr/lib/libglib-1.2.so.0
#28 0x405087b9 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#29 0x406e328c in NSGetModule ()
   from /home/dark/package/components/libwidget_gtk.so
#30 0x40436caa in inflate_mask ()
   from /home/dark/package/components/libnsappshell.so
#31 0x804e435 in nsServiceManager::RegisterService ()Cannot access memory at
address 0x95a8f09
(Assignee)

Comment 3

18 years ago
Image appears fine:

File: gradient.png (822 bytes)
  chunk IHDR at offset 0x0000c, length 13
    2 x 533 image, 24-bit RGB, interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk pHYs at offset 0x00035, length 9: 2834x2834 pixels/meter (72 dpi)
  chunk tIME at offset 0x0004a, length 7: 15 Jan 2001 03:11:58 GMT
  chunk IDAT at offset 0x0005d, length 709
    zlib:  deflated, 32K window, maximum compression
  chunk IEND at offset 0x0032e, length 0
No errors detected in gradient.png (74.3% compression).

#0  0x41ce3991 in png_read_filter_row (png_ptr=0x86eb3c0, row_info=0x86eb51c, 
    row=0x872b799 "", prev_row=0x86fff61 "", filter=4)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngrutil.c:2685
#1  0x41cdba1f in png_push_process_row (png_ptr=0x86eb3c0)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngpread.c:760
#2  0x41cdb924 in png_process_IDAT_data (png_ptr=0x86eb3c0, 
    buffer=0x871c880 "\fÌM£\221\rH÷H", buffer_length=678)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngpread.c:739
#3  0x41cdb74d in png_push_read_IDAT (png_ptr=0x86eb3c0)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngpread.c:683
#4  0x41cda3e7 in png_process_some_data (png_ptr=0x86eb3c0, info_ptr=0x872b670)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngpread.c:59
#5  0x41cda352 in png_process_data (png_ptr=0x86eb3c0, info_ptr=0x872b670, 
    buffer=0x871c880 "\fÌM£\221\rH÷H", buffer_size=694)
    at /cs/src/mozilla/mozilla/modules/libimg/png/pngpread.c:35
#6  0x41cd75eb in il_png_write (ic=0x85d4b00, buf=0x871c880 "\fÌM£\221\rH÷H", 
    len=694) at /cs/src/mozilla/mozilla/modules/libimg/pngcom/ipng.cpp:136
#7  0x41cd81e8 in PNGDecoder::ImgDWrite (this=0x860e4f0, 
    buf=0x871c880 "\fÌM£\221\rH÷H", len=694)
    at /cs/src/mozilla/mozilla/modules/libimg/pngcom/nsPNGDecoder.cpp:106
#8  0x40047d47 in IL_StreamWrite (ic=0x85d4b00, 
    str=0x871c880 "\fÌM£\221\rH÷H", len=694)
    at /cs/src/mozilla/mozilla/modules/libimg/src/if.cpp:1001
#9  0x40043c3f in NetReaderImpl::Write (this=0x86fc840, 
    str=0x871c880 "\fÌM£\221\rH÷H", len=694)
    at /cs/src/mozilla/mozilla/modules/libimg/src/ilNetReader.cpp:108
#10 0x4003a007 in ImageConsumer::OnDataAvailable (this=0x870bed0, 
    channel=0x862d6d8, aContext=0x0, pIStream=0x85b74f4, offset=0, length=822)
    at /cs/src/mozilla/mozilla/gfx/src/nsImageNetContextAsync.cpp:442
#11 0x4135b6b3 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libgklayout.so
#12 0x40f3e1ac in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/liburiloader.so
#13 0x40db756a in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#14 0x40deb859 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#15 0x40d7d01d in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#16 0x40db5a0e in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#17 0x40d4cf6a in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#18 0x40d4c1d0 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnecko.so
#19 0x40122fb4 in PL_HandleEvent (self=0x8633fac)
    at /cs/src/mozilla/mozilla/xpcom/threads/plevent.c:576
#20 0x40122dd5 in PL_ProcessPendingEvents (self=0x8099918)
    at /cs/src/mozilla/mozilla/xpcom/threads/plevent.c:509
#21 0x40124c6e in nsEventQueueImpl::ProcessPendingEvents (this=0x80998f0)
    at /cs/src/mozilla/mozilla/xpcom/threads/nsEventQueue.cpp:356
#22 0x409f8638 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libwidget_gtk.so
#23 0x409f8263 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libwidget_gtk.so
#24 0x408771a0 in ?? () from /usr/lib/libglib-1.2.so.0
#25 0x40878987 in ?? () from /usr/lib/libglib-1.2.so.0
#26 0x40879001 in ?? () from /usr/lib/libglib-1.2.so.0
#27 0x408791cc in ?? () from /usr/lib/libglib-1.2.so.0
#28 0x40792e57 in ?? () from /usr/lib/libgtk-1.2.so.0
#29 0x409f8d09 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libwidget_gtk.so
#30 0x4066dcf9 in ?? ()
   from /ltmp/gfx/tor/mdebug/dist/bin/components/libnsappshell.so
#31 0x080540a1 in main1 (argc=2, argv=0xbffff464, nativeApp=0x0)
    at /cs/src/mozilla/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1030
#32 0x08054bb3 in main (argc=2, argv=0xbffff464)
    at /cs/src/mozilla/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1298
#33 0x40349bfc in __libc_start_main (main=0x80549ac <main>, argc=2, 
    ubp_av=0xbffff464, init=0x804f258 <_init>, fini=0x806008c <_fini>, 
    rtld_fini=0x4000d674 <_dl_fini>, stack_end=0xbffff45c)
    at ../sysdeps/generic/libc-start.c:118

Comment 4

18 years ago
Looks like a libpng bug.  Greg Roelofs' "rpng-2" (from the contrib/gregbook
directory of libpng distribution) crashes in the same manner, in
png_read_filter_row().

Glenn
Status: NEW → ASSIGNED

Comment 5

18 years ago
pngcheck without the -vv option does not look inside the IDAT chunk(s), which is
where the problem (seemingly) lies:

File: moz65471-2x533.png (822 bytes)
  chunk IHDR at offset 0x0000c, length 13
    2 x 533 image, 24-bit RGB, interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk pHYs at offset 0x00035, length 9: 2834x2834 pixels/meter (72 dpi)
  chunk tIME at offset 0x0004a, length 7: 15 Jan 2001 03:11:58 GMT
  chunk IDAT at offset 0x0005d, length 709
    zlib:  deflated, 32K window, maximum compression
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      0 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 253 252 250 2 0 0 0
      2 255 255 253 2 255 255 255 2 0 0 0 2 1 1 1 2 253 253 253 2 0 0 255 2
      1 254 0 2 0 0 0 2 248 251 250 2 8 4 5 2 255 255 255 2 0 0 0 2 255
      255 252 2 255 0 253 2 2 253 253 0 255 255 255 255 0 0 254 255 251 255 255
255 253 255
      254 255 253 254 255 0 252 0 252 0 253 255 255 0 1 255 255 0 252 0 253 255
0 255 254
      255 254 255 4 255 1 255 255 0 1 250 0 0 0 255 254 255 0 0 0 1 254 255 0
255
      0 0 2 0 0 0 2 0 0 0 2 0 0 0 0 255 255 251 2 246 245 245 2 3 0
      1 0 255 250 247 2 250 250 250 2 0 0 0 2 0 0 0 2 0 0 0 2 255 255 252
      2 0 0 0 2 255 0 253 2 0 0 0 2 3 254 254 2 255 255 255 2 0 0 0 2
      0 0 0 2 255 255 255 2 0 0 0 2 0 0 0 2 255 255 255 2 0 1 255 2 255
      255 255 2 0 0 0 2 0 0 0 2 255 254 0 2 255 255 255 2 1 1 1 2 255 255
      255 2 0 1 255 2 0 0 0 2 0 255 0 255 0 255 0 255 0 0 2 255 255 255 0
      0 255 0 2 0 255 255 0 255 0 255 0 255 0 255 1 255 0 0 0 0 255 0 255 0
      0 255 2 0 0 255 0 255 0 0 0 255 1 255 2 0 255 0 0 0 255 0 253 0 255
      0 1 255 0 0 0 0 255 0 1 0 0 255 0 1 0 0 0 253 0 0 0 0 0 0
      0 255 0 0 0 255 0 0 0 0 0 0 0 0 1 0 254 255 0 0 0 0 0 0 0
      1 0 0 0 0 0 0 0 251 250 255 242 3 7 4 249 1 0 0 0 0 0 0 0 255
      0 0 0 255 0 0 0 2 1 255 0 0 0 0 0 255 0 0 0 0 0 255 0 1 255
      0 255 0 0 0 0 0 255 0 255 2 255 0 255 0 0 0 0 0 0 255 0 0 0 255
      0 0 0 255 0 0 0 0 255 0 0 0 0 0 0 255 0 0 255 0 255 2 0 0 0
      255 0 0 0 0 0 2 0 255 0 255 0 0 0 255 0 0 0 0 255 0 0 255 0 0
      0 0 255 0 0 255 0 0 0 0 0 0 0 0 0 255 0 0 0 255 0 0 0 0 0
      0 255 1 0 0 0 0 0 255 0 0 0 255 0 0 0 0 0 2 255 0 255 2 255 0
      255 1 0 0 0 255 0 0 0 0 0 0 0 255 0 0 0 255 0 0 0 255 0 0 0
      0 1 0 255 0 0 0 0 0 255 0 0 255 0 0 0 1 0 0 0 0 0 255 0 0
      0 1 0 0 0 0 0 0 0 255 253 0 0 0 0 2 0 0 0 0 0 0 2 0 255
      0 0 0 254 2 0 255 0 0 0 0 2 0 0 0 0 0 0 2 0 0 0 1 0 255
      4 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 1 253 255 6
      249 249 253 249 255 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
      255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 255 0 0 0 0 0 0 0 0 0
      0 0 0 0 0 0 255 1 0 0 0 1 0 0 255 1 0 0 0 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
      0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 255 0 (973 out of 1001)
  chunk IEND at offset 0x0032e, length 0
No errors detected in moz65471-2x533.png (74.3% compression).

However, I think this version of pngcheck has a bug in its deinterlacing code,
so I don't believe the filter values it reports.  I'll try to fix pngcheck ASAP.

As Glenn reported, rpng2-x fails; this is both with and without MMX code enabled
(though for this image width, the code paths are probably identical and
non-MMX).  XV using libpng 1.0.5 works fine.  NN 4.7/Linux doesn't barf but also
doesn't display the image.

So I agree with Glenn:  it looks like we somehow introduced a deinterlacing bug
in newer versions of libpng--or perhaps a bug that was fixed in the stock C code
was reintroduced in the C part of the MMX code?  I don't know if Mozilla is
using the latter, but the version of rpng2 I tested definitely was.

Greg

Comment 6

18 years ago
OK, after incorporating Glenn's pngcheck fix from 27 July, the image looks just
fine:

File: moz65471-2x533.png (822 bytes)
  chunk IHDR at offset 0x0000c, length 13
    2 x 533 image, 24-bit RGB, interlaced
  chunk gAMA at offset 0x00025, length 4: 0.45455
  chunk pHYs at offset 0x00035, length 9: 2834x2834 pixels/meter (72 dpi)
  chunk tIME at offset 0x0004a, length 7: 15 Jan 2001 03:11:58 GMT
  chunk IDAT at offset 0x0005d, length 709
    zlib:  deflated, 32K window, maximum compression
    zlib line filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
      0 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 0 2 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
      2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 4 2 4 2 4 2 2 2
      2 2 2 2 2 4 4 4 4 4 2 2 4 2 2 2 4 2 2 2 2 2 2 2 2
      2 2 1 4 0 1 4 4 2 2 2 2 2 2 2 4 4 2 2 4 2 2 2 4 2
      4 2 2 2 2 2 4 2 2 2 2 2 4 2 4 2 4 2 2 2 2 2 2 4 2
      4 4 4 2 4 4 2 2 2 2 4 2 4 4 2 4 2 2 4 2 2 2 4 2 4
      2 2 2 2 2 4 2 4 2 2 4 2 4 2 2 2 4 2 2 2 4 2 2 2 4
      2 4 2 2 4 2 2 2 2 4 2 4 2 4 2 2 2 4 2 2 2 4 2 2 2
      2 2 2 2 2 2 4 2 2 2 4 2 2 2 2 2 4 2 2 2 2 2 2 2 4
      2 2 4 2 2 2 2 2 2 2 4 2 4 4 4 2 4 2 2 2 2 4 2 2 2
      2 2 2 2 4 2 2 2 4 2 2 2 4 2 2 2 4 2 4 2 2 2 2 2 4
      2 2 2 4 2 2 2 4 2 2 2 2 4 2 2 4 2 4 2 2 2 2 2 4 2
      (800 out of 800)
  chunk IEND at offset 0x0032e, length 0
No errors detected in moz65471-2x533.png (74.3% compression).

Comment 7

18 years ago
I have libpng reading the file properly.  I'll post libpng-1.0.9beta9
to the png ftp site and libpng.sourceforge.net shortly.

The problem was that pngpread.c was not taking empty passes into account.
It is not a new bug; this fault has always existed.  I don't know why it
hasn't been noticed before.

Glenn

Comment 8

18 years ago
I guess that means that there aren't that many progressive PNG readers (like
Mozilla and rpng2), combined with the fact that there aren't many skinny,
interlaced PNGs around.  XV isn't a progressive decoder, so it didn't trigger
the bug.  I'll bet the bug was reported and fixed a long time ago in pngread.c,
but the fix simply didn't get copied over to pngpread.c.

Btw, the 1x1 interlaced PNG from Willem's PngSuite worked just fine.

Comment 9

18 years ago
Libpng-1.0.9beta9 is available at http://libpng.sourceforge.net/

Someone please build Mozilla with it and make sure it fixes the problem
and doesn't introduce new ones.

Glenn
(Assignee)

Comment 10

18 years ago
Using 1.0.9beta9 fixed this problem and hasn't caused any others yet in
informal testing.
(Assignee)

Comment 11

18 years ago
Taking bug.
Assignee: pnunn → tor
Severity: critical → normal
Status: ASSIGNED → NEW
Keywords: crash
Target Milestone: --- → mozilla1.0
Tim,

In your info_callback function you will want to add a safety check so
older versions of libpng don't crash, along these lines:

    if (interlace_method != 0 && width < 5)
#if PNG_LIBPNG_VER >= 10007                      /* version compiled with */
        if (png_access_version_number() < 10009) /* version running with */
#endif
            png_error(png_ptr,
            "libpng-1.0.9 or later is needed to decode narrow interlaced PNGs");

This code would go right after you have decoded the IHDR chunk.
Glenn
(Assignee)

Comment 13

18 years ago
Now that libpng 1.0.9 is out, we should update to that.  Along with the
usual update to modules/libimg/png, we need to tweak configure.in:

Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.774
diff -u -r1.774 configure.in
--- configure.in        2001/02/01 20:36:43     1.774
+++ configure.in        2001/02/03 07:12:15
@@ -75,7 +75,7 @@
 dnl Set the version number of the libs included with mozilla
 dnl ========================================================
 MOZJPEG=62
-MOZPNG=10008
+MOZPNG=10009
 MOZMNG="((0<<16)|(9<<8)|(4))"
 NSPR_VERSION=4
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Target Milestone: mozilla1.0 → mozilla0.8
(Assignee)

Comment 14

18 years ago
mozilla libpng updated to 1.0.9
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 15

18 years ago
Verified Win build 2001031220
Verified Linux build 2001031308
Verified Mac build 2001031309
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.