Last Comment Bug 622816 - Loading a large image can "freeze" firefox, or crash the system
: Loading a large image can "freeze" firefox, or crash the system
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: Trunk
: All All
-- critical with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Milan Sreckovic [:milan]
Depends on: 1060869
  Show dependency treegraph
Reported: 2011-01-04 06:31 PST by Michal 'hramrach' Suchanek
Modified: 2014-12-31 04:24 PST (History)
14 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Michal 'hramrach' Suchanek 2011-01-04 06:31:24 PST
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110103 Firefox-4.0/4.0b9pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110103 Firefox-4.0/4.0b9pre

I was testing a download bug and found this one because I needed a file that takes noticeable time to download and is kept in cache. I used

which I found by searching for "high resolution images".

Loading one of the larger files on a PC with 4G ram leads to Firefox "freezing", overall system performance degradation to the point of "freezing" and X server crashing.

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110103 Firefox-4.0/4.0b9pre

Reproducible: Always

Steps to Reproduce:
1. follow the link to one of the larger images on the site in Firefox
Actual Results:  
Firefox "freezes" and so does the whole system due to excessive swap use

Expected Results:  
Firefox refuses to automagically render bitmas gigabytes in size

Firefox needs to limit the largest bitmap it will display without asking.

This is a security issue.

Anybody can post links to large images that when opened in Firefox could cause DoS on the user machine or data loss due to exhausting system resources and crashing the system. Note that the image file itself need not be large, I bet a few gigabytes of pure black compress well.

There is no way to tell how large the image is in advance so loading *any* image link can potentially crash your computer.

What's worse, the image can be embedded in an img tag on a forum that you visit and that allows posting links to images that way (quite common).

Large images could be replaced with a stub like NoScript or FlashBlock extensions replace plugin content (more appropriate when displayed in a web page) or Firefox could display a dialog asking for confirmation (more appropriate when loading the image directly).
Comment 1 User image Michal 'hramrach' Suchanek 2011-01-04 11:38:26 PST
I don't think this is about ImageLib.

It can be improved (and already was) to handle large images better but however well it performs you can always come with an image that is beyond the posibilities of ImageLib on the system in question.
Comment 2 User image Daniel Holbert [:dholbert] 2011-01-04 12:17:40 PST
I filed Bug 622928 on a possibly-related hang / system-lockup regression that happens specifically when you *interrupt* the loading of a giant image (even if you interrupt it after it's just barely started loading).
Comment 3 User image Michal 'hramrach' Suchanek 2011-01-04 12:33:02 PST
Yes, it may be related. The crash I had was after interrupting loading of a picture.

Still you are bound to exhaust the system memory even with properly working ImageLib unless there is some limit in place on the size of images Firefox tries to load.
Comment 4 User image Hugh Coleman 2011-05-30 10:51:10 PDT
Just happened to me loading an image from Wikipedia. Firefox crashed with no warning.
Comment 5 User image utkjamie 2011-06-08 16:52:51 PDT
Same problem has been happening to me over the past week or two in Debian Squeeze. It's not consistent, but when I've had a single large image freeze the entire computer, forcing me to kill the power to reboot (which is potentially disastrous on an EXT4 file system). I can load the same image and multiple tabs with other large images in Google Chrome without a problem, though, so whatever is going on seems to be limited to Firefox.
Comment 6 User image TinyButStrong 2011-08-26 06:14:22 PDT
No problem here (Seven x64), except for the CPU usage a little high (43%).
Comment 7 User image Michal 'hramrach' Suchanek 2011-08-26 06:46:16 PDT
And what Firefox and X server?
Comment 8 User image Shriram (irc: Mavericks) Away 2012-08-29 08:17:25 PDT
Does it occur with the latest stable version also Michal ?
Comment 9 User image david.smitmanis 2012-08-31 09:29:08 PDT
I can comfirm this is still an issue in both Firefox 15 and 18 (current Nightly).

Click one of the larger images on the link provided, watch the browser use up all RAM, then all Swap, and then crash. Using Ubuntu Linux on a system with 1gb RAM, so it crashes quite fast.

Tried it on a Windows 7 system with 6gb RAM. It used up to 2.5GB RAM, although it never crashed.

Compared it to Chrome. There the image just wouldn't load, and the RAM usage never shot up noticably at all.

Suggestion: Change status to Confirmed
Comment 10 User image Gunter Königsmann 2013-04-25 21:51:44 PDT
Seems like a duplicate of Bug #739159 to me.
Comment 11 User image Gunter Königsmann 2013-04-25 21:52:41 PDT
Looks like a duplicate of Bug #739159 to me.
Comment 13 User image Christopher Booth 2013-12-02 13:45:24 PST
A partial solution to this problem is to make it an easy option to shut off loading images. At the same time, not using javascript also needs to be added. These are essential options. I checked to see if they had been added to 25, they have not, so I will continue to use 22, which does have both of those options. It was a really bad decision to eliminate them with 23.
Comment 14 User image Seth Fowler [:seth] [:s2h] 2014-12-29 15:07:04 PST
I can't reproduce this on Nightly. The switch to storing images in the ImageLib SurfaceCache has totally solved this problem, because the SurfaceCache enforces a hard upper limit on the amount of memory we will devote to images.

Can anyone still reproduce on Nightly? If not, I'm going to resolve this bug.
Comment 15 User image :Hb 2014-12-31 04:24:06 PST
(In reply to Seth Fowler [:seth] from comment #14)
> Can anyone still reproduce on Nightly? If not, I'm going to resolve this bug.

Checking with Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 on a low end Atom machine and with  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:37.0) Gecko/20100101 Firefox/37.0 on a quad core gives similar good results.  While the Firefox process eats one core completely (~25 % CPU load) the Firefox UI remains usable.  New tabs can be created and content in that tabs is loaded.

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