Closed Bug 74270 Opened 23 years ago Closed 23 years ago

Browser crashes after downloading part of the page

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: mozilla, Assigned: pavlov)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [imglib])

Attachments

(3 files)

Stack trace. Get by setting breakpoint to exit()
5.44 KB, text/plain
Details
fix for crash
1.79 KB, patch
Details | Diff | Splinter Review
fix for brendan's nitpicks.
1.45 KB, patch
Details | Diff | Splinter Review 
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
Keywords: crash
Works for me linux build 2001040405, closing as worksforme Reporter, if you have 
more details, please feel free to reopen
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
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.
URL: http://http://www.geckonnection.com/w... → http://www.geckonnection.com/webfilme...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Crashes with PC Linux 2001041208.

Same error messages
Blocks: 66967
Crashes on linux build 2001041205, adding [imglib] status whiteboard
Whiteboard: [imglib]
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. ***
Attached patch fix for crash — — Splinter Review 

    
  
Status: NEW → ASSIGNED
Keywords: patch

    
    

    
  
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
Target Milestone: --- → mozilla0.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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
Verified fixed mac build 2001051705
Verified fixed w98 build 2001051704
Verified fixed linux build 2001051706
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: