Closed Bug 321581 Opened 19 years ago Closed 17 years ago

large image crashes firefox

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: eric, Assigned: glennrp+bmo)

References

(
URL
)

Details

Attachments

(2 files, 5 obsolete files)

GIF image that crashes mozilla 1.7.12
(deleted), image/gif
Details
set image limits via config or env (dimensions or max pixels)
(deleted), patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051224 Debian/1.5.dfsg-3 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051224 Debian/1.5.dfsg-3 Firefox/1.5

http://gregory5.free.fr/path_graph_200512.png and http://nms.lcs.mit.edu/6.829/6829-tas-email.png crash firefox everytime pages that include them are loaded. May be a bug in libpng, but other png based programs seem to have no problem with them.

Reproducible: Always

Steps to Reproduce:
WFM, Firefox 1.5 and trunk Linux (SuSE 9.x).

If you start Firefox in a shell, do you see any error messages before it crash?
Does the latest trunk build also crash?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Of course I meant to do this, here is the only output: 

The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 36111 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

See also bug 210931 and friends.
Depends on: 210931
WFM, Seamonkey trunk downloaded 051222, built with either libmng or libpng
supporting png.  It takes about 10 minutes either way, and also takes
about 10 minutes to show the image in GIF format (see
http://www.simplesystems.org/users/glennrp/mozilla/bug321581).  It would
be useful to know if the GIF also crashes on those platforms where the
PNG crashes.
Attached image GIF image that crashes mozilla 1.7.12 (deleted) — 

    
    

    
  
Bank of Finland web page at

http://www.bof.fi/fin/0_new/0.1_valuuttak/

includes taustakuva.gif which seems to crash mozilla 1.7.12 on debian sarge
in a similar way:

apps1$ /opt/mozilla-1.7.12/mozilla file://`pwd`/taustakuva.gif
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
  serial 1666 error_code 11 request_code 53 minor_code 0
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
  serial 1668 error_code 9 request_code 72 minor_code 0
apps1$ 

    
    

    
  
Taking bug, removing word "png" from summary.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: large png image crashes firefox → large image crashes firefox

    
  
Assignee: nobody → glennrp
Status: ASSIGNED → NEW

    
    

    
  
The issue is bad enough to a humble block status request.
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?

    
    

    
  
glenn: why isn't this just a dupe of the blocker?
Whiteboard: DUPEME

    
    

    
  
The blocker is addressing the issue of X11 resources and the ability of
X11 to pass an error message back to the caller.  I am thinking of the
possibility of heading off the problem earlier by having each image decoder
reject too-large images right away instead of decoding the whole thing (or
at least some rows) and then passing it to X11 where it is doomed.

This would of course miss attempts to make too-wide displays by means other
than wide images, such as using HTML <img width=15000 ...> but if you look
at the duplicate bug reports they are mostly caused by actual wide images.

Checking the image dimensions in the decoders is easy, almosttrivial.  Most
of them already do check, but with large values (65500 for JPEG, 1000000 for PNG).
These values could be overridden by a configuration setting, like
MOZ_MAX_IMAGE_WIDTH.  Then, on those Linux platforms where the real limit
is 8192 or whatever it is, the builder can set MOX_MAX_IMAGE_WIDTH=8192
in their .mozconfig.

    
    

    
  
the problem is generally per x11 server and not per os hosting gecko. so if you're going to do it, it really should be runtime controlled either via an env var (more sensible since the xserver for a given user profile can change fairly randomly) or via a preference. perhaps the thing to do is to actually manually speak x11 to the server early on and try to dynamically determine what the limits are?

    
    

    
  
Good point.  If it's user selectable then there will be some impact on executable size (maybe a few hundred bytes), while if it's configurable then there is only an impact if the builder sets the flag.  I'll make two patches, one that does it each way, and we can do some testing.  Dynamic determination of limits is going to be tough and I guess will require solution of bug #210931.  I can't find a simple query for limits in my Xlib manuals, and I'm leery of running tests with a wide or tall image during startup because we don't really want to give the browser more work to do during startup.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        configure image limits (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  
This allows the builder to configure MOZ_MAX_IMAGE_WIDTH and/or MOZ_MAX_IMAGE_HEIGHT.

    
    

    
  
There's already a central test, in gfxImageFrame::Init().


    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch to set image limits via configure or env (obsolete) (deleted)
        — 
          — Splinter Review
      

    


  
Thanks tor, that makes it a lot simpler.  This patch allows the builder to set limits via --enable-max-image-width=NNNN or via GECKO_MAX_IMAGE_WIDTH=NNNN in the environment.  The environment variable takes precedence over the configuration setting.  These tests are skipped for images with both dimensions <= 2000 which is the usual case.

        Attachment #207690 -
        Attachment is obsolete: true

    
    

    
  


  
There were a couple of typos in previous patch, fixed now.

        Attachment #207788 -
        Attachment is obsolete: true

    
    

    
  


  
Sorry, more typos (IMG -> IMAGE)

        Attachment #207790 -
        Attachment is obsolete: true

    
    

    
  
Isn't the total width*height a better heuristic?

    
    

    
  
The bug reports seem to be talking about failures with wide images rather than images with too many pixels.  It would be simple enough to add a GECKO_MAX_IMAGE_PIXELS test, at little additional cost, if you think users would prefer to use that, to limit their memory consumption.  Note that the original tests for width*height overflow are still in there.

    
    

    
  


  

        Attachment #207791 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 207812 [details] [diff] [review]
set image limits via config or env (dimensions or max pixels)

I misplaced a "}" while adding the width*height feature.  Will supply a corrected patch later today.

        Attachment #207812 -
        Attachment is obsolete: true

    
    

    
  
If you're going to come up with a real patch, I'd suggest starting with something that catches the gdk error and fails in some way other than crashing.  Not really sure what that is, but a patch to add a user pref, environment variable or a compile-time-option is pretty worthless.

    
    

    
  


  
The "dupe" has been around for 2.5 years.  This was meant as a quick fix.
Also it allows people to save some resources by telling the browser to
bail out early on big images instead of waiting for the full decode followed
by error generation and trapping.  This feature can coexist with a fix
for the dupe.
Flags: blocking1.8.0.1? → blocking1.8.0.1-

    
    

    
  
Might be considered for a 1.8.0.x release if it were landed on the trunk and well tested. Too late for 1.8.0.1 though

    
    

    
  
The patch works equally well when applied against a MOZILLA_1_8_BRANCH checkout.

I noticed that the GIF decoder ignores the error return from gfx Init(), while
the PNG, JPEG, and BMP decoders all respond correctly.

    
    

    
  
One reasonable way of fixing this would be splitting images with a dimension greater than some size (say, 8k) into multiple pixmaps for rendering.  This would require some rework in the image rendering code, which can probably be done at the same time that we optimize image stuff for new-world rendering.  Adding in env vars and configure options isn't the right solution.


    
    

    
  
That concept is easy enough to test.  Using one of the platforms that crashes on wide images, look at
http://www.simplesystems.org/users/glennrp/mozilla/bug321581/side_by_side.html
which contains three 4000-wide images displayed side-by-side in a table.

    
    

    
  
This approach may be fruitless in preventing crashes.  It seems that when this method is used to detect an over-wide image, the browser then tries to display a broken-image icon with the same large dimensions.  I guess that will also trigger the same crash.

    
    

    
  
The attached GIF doesn't crash my FF 1.5, but the images (even the "smallest" 5mb one) from http://visibleearth.nasa.gov/view_detail.php?id=7100 (http://veimages.gsfc.nasa.gov//7100/world.topo.bathy.200401.3x21600x21600.A2.jpg)

    
    

    
  
this works properly in:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060214 Firefox/1.6a1

please change this to FIXED.

    
    

    
  
No patch has been checked in here, nor in bug 210931, so FIXED is not the
right resolution. If the crash can't be reproduced it's WORKSFORME, but I doubt
that is the case.

    
    

    
  
The bug is still there in FF 2.0.0.1 / Linux (Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.1) Gecko/20061208).

Try this url, it will crash your browser reproducable:

ftp://tug.ctan.org/ftpmaint/CTAN_lion/ctan_lion_2400.png

It's a 39M file, but .. hey I've got 1G RAM ;-).


    
    

    
  
(In reply to comment #32)
> The bug is still there in FF 2.0.0.1 / Linux (Mozilla/5.0 (X11; U; Linux i686;
> de; rv:1.8.1.1) Gecko/20061208).
> 
> Try this url, it will crash your browser reproducable:
> 
> ftp://tug.ctan.org/ftpmaint/CTAN_lion/ctan_lion_2400.png
> 
> It's a 39M file, but .. hey I've got 1G RAM ;-).
> 

This crashes too on that image (after a few minutes, scroll bars appear, then the browser window disappears):

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070113 Minefield/3.0a2pre (Enf... SVG,MNG)

Using libmng to render PNG files.

    
    

    
  
(In reply to comment #33)
> > Try this url, it will crash your browser reproducable:
> > 
> > ftp://tug.ctan.org/ftpmaint/CTAN_lion/ctan_lion_2400.png
> > 
> > It's a 39M file, but .. hey I've got 1G RAM ;-).
> > 
> 
> This crashes too on that image (after a few minutes, scroll bars appear, then
> the browser window disappears):
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070113
> Minefield/3.0a2pre (Enf... SVG,MNG)
> 
> Using libmng to render PNG files.

I cannot reproduce this on Windows Vista with the latest nightly.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101605 Minefield/3.0a9pre ID:2007101605

    
    

    
  
The ctan_lion_2400.png image has dimensions 8200x7280.  It is the image
dimensions, not whether it is being decoded by libpng or libmng or gif.c
for that matter, that cause the problem.  I proposed a patch nearly two
years ago that will reject overly large images instead of crashing the
browser.  If you like I'll try to rewrite it to use a preference instead
of an environment variable.
Status: NEW → ASSIGNED

    
    

    
  
(In reply to comment #35)
> The ctan_lion_2400.png image has dimensions 8200x7280.  It is the image
> dimensions, not whether it is being decoded by libpng or libmng or gif.c
> for that matter, that cause the problem.  I proposed a patch nearly two
> years ago that will reject overly large images instead of crashing the
> browser.  If you like I'll try to rewrite it to use a preference instead
> of an environment variable.

Sorry if I'm being stupid, but just to clarify, if it's the image dimensions that cause a problem on Linux, why did using libmng on Windows also cause a problem?

    
    

    
  
I guess I'm stupid too because I don't know.  Viewing the image on WinXP
using Firefox 2.0.0.6/libpng displayed about 150 rows of the top of the image
in about 30 minutes, and gave me a warning about running out of virtual
memory.  But I got bored and killed it so I don't know if it would have
eventually crashed or not.  I'll fire it up again later tonight, and see
in the morning what happened.

    
    

    
  
OK, on the second try I got no warnings about memory, and it took just short
of two hours to decode the image.  Even after decoding the computer was
very sluggish; attempts to scroll would take 10-15 minutes to respond, and
even closing the tab took about 15 minutes.  But there was no crash, so there
is no error to trap.  This is on WinXP with 256MB memory, downloading over
cable.

    
    

    
  
I have this bug in my Firefox (Fedora 7, Gecko/20071019 Fedora/2.0.0.8-1.fc7 ).

I created a black PNG image of 24000 * 20 and tried to open it: Firefox crashes.
I can open this image with Opera 9.24.

I understand these images are quite large and not very common on the web, but in my company we use http://www.viewvc.org/ that generates such larges pictures when there are a lot of branches on a file.


    
    

    
  
Laurent, can you attach examples of such PNG's?
(24000*20*4 = 1920000 bytes = 2MB, so should perfectly ok in FF).
(and note FF3 has many improvements on image handling, so that may have fixed this issue as well)

    
    

    
  
Note, all examples (that are still available) provided in this bug do work ok in FF3.0b2pre: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007111805 Minefield/3.0b2pre.

So, this can be considered FIXED by Cairo (in general), and bug 371135 specifically.

Note, FF3 reports on the ftp://tug.ctan.org/ftpmaint/CTAN_lion/ctan_lion_2400.png testcase:
           Key: file:///c:/tmp/png/ctan_lion_2400.png
     Data size: 238784000 bytes
   Fetch count: 1
 Last modified: 2007-11-19 15:33:06
       Expires: No expiration time

So, it indeed uses a lot of memory, but it doesn't crash anymore.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED

    
  
Whiteboard: DUPEME

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: