Browser crashes after downloading part of the page

VERIFIED FIXED in mozilla0.9



17 years ago
17 years ago


(Reporter: Ronald van Kuijk, Assigned: Stuart Parmenter)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [imglib], URL)


(3 attachments)



17 years ago
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 ;-)

Comment 1

17 years ago
Wfm with 2001033108 / Win98SE


17 years ago
Keywords: crash

Comment 2

17 years ago
Works for me linux build 2001040405, closing as worksforme Reporter, if you have 
more details, please feel free to reopen
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 3

17 years ago
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:

I wil try it on a vanilla installation this weekend 

Resolution: WORKSFORME → ---

Comment 4

17 years ago
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...

Comment 5

17 years ago
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.
Ever confirmed: true

Comment 6

17 years ago
Crashes with PC Linux 2001041208.

Same error messages
Blocks: 66967

Comment 7

17 years ago
Crashes on linux build 2001041205, adding [imglib] status whiteboard
Whiteboard: [imglib]

Comment 8

17 years ago
FYI, not able to get talkback to come up

Comment 9

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

Comment 10

17 years ago
Created attachment 30671 [details]
Stack trace. Get by setting breakpoint to exit()

Comment 11

17 years ago
This is probably a dup of bug 73556.

Comment 12

17 years ago
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

Comment 13

17 years ago
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 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

Comment 15

17 years ago
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 :)

Comment 16

17 years ago
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.

Comment 17

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

Comment 18

17 years ago
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.

Comment 19

17 years ago
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.

Comment 20

17 years ago
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

Comment 21

17 years ago
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.

Comment 22

17 years ago
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...

Comment 23

17 years ago
*** Bug 76713 has been marked as a duplicate of this bug. ***
*** Bug 77086 has been marked as a duplicate of this bug. ***

Comment 25

17 years ago
Created attachment 31816 [details] [diff] [review]
fix for crash


17 years ago
Keywords: patch

Comment 26

17 years ago
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.

Comment 27

17 years ago
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.

Comment 28

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

Comment 29

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

Comment 30

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

Comment 31

17 years ago
moving to 0.9
Target Milestone: --- → mozilla0.9
So pav owes us a new patch that doesn't waste cycles on unit scaling.


Comment 33

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

Comment 34

17 years ago
Created attachment 31962 [details] [diff] [review]
fix for brendan's nitpicks.
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


Comment 36

17 years ago
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

Comment 38

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

Comment 39

17 years ago
fix checked in.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 40

17 years ago
Verified fixed mac build 2001051705
Verified fixed w98 build 2001051704
Verified fixed linux build 2001051706
You need to log in before you can comment on or make changes to this bug.