From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16 i686) BuildID: 2001033105 Browser crashes after downloading part of the page. console text: libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Ignoring truncated iCCP profile. Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 28444 error_code 8 request_code 73 minor_code 0 Reproducible: Always Steps to Reproduce: 1. Go to the Above url Actual Results: Browser crashes Expected Results: No crash ;-)

Wfm with 2001033108 / Win98SE

Works for me linux build 2001040405, closing as worksforme Reporter, if you have more details, please feel free to reopen

It still crashes on this page on my computer using linux build 20010405.. I am running Suse 7 (kernel 2.2.16) with a fairly recent 'ximian-gnome' and sawfish as a windowmanager, but I have done many 'upgrades' Versions of libraries: libpng.so.2.1.0 libgdk-1.2.so.0.5.3 libgdk_imlib.so.1.9.8 libgdkmm-1.2.so.1.0.0 libgdk_pixbuf.so.2.0.0 libgdk_pixbuf_xlib.so.2.0.0 I wil try it on a vanilla installation this weekend

On a clean suse7 installation with the most recent ximian-gnome still crashes the browser on this page (linuxbuild 2001041208). I'd be happy to provide more info, If I only knew how...

Confirming. I get this on today's Linux gcc295 build. Doesn't look like a dupe of 74270, because it's not an XIE problem.

Crashes with PC Linux 2001041208. Same error messages

Crashes on linux build 2001041205, adding [imglib] status whiteboard

FYI, not able to get talkback to come up

Cannot get stack trace due it seems to *quit* - it is not a real crash.

This is probably a dup of bug 73556.

I dont know if its a dup but have some other info.. I save all 4 parts of this page (1 html, 1 png and 2 gifs) with Netscape 4.7 and loaded it from hardisk. guess what? *NO* crash/exit..... So probably the loading results in a corrupt png which causes this behaviour... Maybe imglib is not the real cause of this problem.

Wow... moving the mouse in this page (loaded locally) really hogs my cpu.... Probably another bug somewhere.. but what is the culprit? style/layout/js/...

yow, this crashes the browser for me --but unfortunately talkback doesn't seem to have a chance to run: no stack trace. :( [using 2001.04.12.08 verif bits.] don't think this is a dup of bug 73556, since that one works for me. here's the console output: Document http://www.geckonnection.com/webfilmed/bluemask loaded successfully libpng warning: Incomplete compressed datastream in iCCP chunk libpng warning: Ignoring truncated iCCP profile. Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 22262 error_code 8 request_code 73 minor_code 0

sairuh: you don't get tallback because on this error gdk calls exit() which is the "normal" way to quit from C/C++ application. If you compare the stack traces from this bug and bug 73556 you see they are very similar - but you are right these bugs can be separate ones. Interesting thing with this bug is that it seems to be very hard to reproduce this "crash" when running debug build in the debugger. BadMatch error simply won't happen. If needed I can try to debug this more but tomorrow. Now it is time to get some sleep (here it is 03:08 AM :)

With Linux build from CVS (evening 2001-04-17), browser no longer crashes. I'm not sure how fast the PNG (it appears to be animated) is supposed to update. This warning is still displayed: libpng warning: Incomplete compressed datastream in iCCP chunk I think might have become a worksforme.

Still crashes for me on most recent build (2001041708), wil try tomorrow with a 20010418xx build.

iCCP chunk defines device profiles which are used to match colors between different devices. There seems to be some kind of decompression problem with the picture according to libpng. http://www.libpng.org/

The iCCP chunk warning is associated with PNG images created by a buggy version of Photoshop. Adobe screwed up, but the image should look fine anyway. This warning is coming from libpng, I doubt that it's related to the Mozilla crashes directly.

I agree that the iCCP messages are not the direct cause of the 'exit'. I get them as well when I load this page from my HD but *without* mozilla exiting. The GDK error is probably the cause, but why does this only happen when loading via http?

I copied the 4 files of this page to my webservers (Tomcat and NES) and loaded them via http. In both cases Mozilla does not exit!!. Bear in mind that I got these files via Netscape4.7 from the original URL.

First of all sorry I didn't put all these comments in one message. Now the additional info: When I load the individual images from the original location with Mozilla (linuxbuild 2001041808) there is no exit in Mozilla. Even when I then load the html page (and the images come from cache) Mozilla does not exit. A normal reload (without shift) keeps mozilla alive. Only a forced reload (with shift) results in mozilla exiting. I hope this helps...

*** Bug 76713 has been marked as a duplicate of this bug. ***

*** Bug 77086 has been marked as a duplicate of this bug. ***

Thanks for the fix but there seems to be a bug in the fix. You first adjust widths/heights to fit inside to mDecodedX2 and mDecodedY2 but then you possibly move starting points (aSX, aSY, aDX, aDY) so you may end up to widths and heights that are too big. So you should first adjust starting points and then the widths and heights.

And origSHeight == origDHeight and origSWidth == origDWidth so you multiply with 1: + aDWidth -= ((aSX + aSWidth - mDecodedX2)*origDWidth)/origSWidth; + aDX += ((mDecodedX1 - aSX)*origDWidth)/origSWidth; + aDHeight -= ((aSY + aSHeight - mDecodedY2)*origDHeight)/origSHeight; + aDY += ((mDecodedY1 - aSY)*origDHeight)/origSHeight; so you don't need orig* variables.

BTW DrawScaled has the same bug that widths and heights can be too large due moving the starting points.

I said: "So you should first adjust starting points and then the widths and heights." Forget that. That don't help anything.

Not seeing the crash with this patch applied to 2001-04-23-21 on Linux.

moving to 0.9

So pav owes us a new patch that doesn't waste cycles on unit scaling. /be

Hopefully he will also fix that width and height problem when starting point is moved.

As you know, the comments about wasted cycles were not nit-picks -- sloppy code like that is just minor bloat in instruction memory and CPU time, but it does not pass for a "nit". Now calling temporaries j and z when j is not a column index or Bessel function prefix, and z is not a 3d coord (XUL3D!) or complex number -- those are nits! Anyway, tor and I are not sure whether you want to return NS_OK both times, or NS_ERROR_FAILURE both times you return early on degenerate draws (0 or negative width or height). I think NS_OK, assuming anyone cares about the r.v. If you don't believe anyone should ever call with such inputs as to lead to either of those early returns, NS_ASSERTION(aSWidth > 0 && ...); before each if. Straighten that not-quite-nit out and r=brendan@mozilla.org. /be

Only the first early exit condition is assertable - the other could happen in normal operation if you get the right combination of decode rect and source rect. Fix brendan's non-nit and sr=tor.

r=blizzard, a=blizzard for 0.9

Adding the assert causes assertions on this page. I've filed bug 77298 on the assertion and I will investigate that.

fix checked in.

Verified fixed mac build 2001051705 Verified fixed w98 build 2001051704 Verified fixed linux build 2001051706