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 http://visibleearth.nasa.gov/view_detail.php?id=7100 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).

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.

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).

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.

Just happened to me loading an image from Wikipedia. Firefox crashed with no warning.

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.

No problem here (Seven x64), except for the CPU usage a little high (43%).

And what Firefox and X server?

Does it occur with the latest stable version also Michal ?

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

Seems like a duplicate of Bug #739159 to me.

Looks like a duplicate of Bug #739159 to me.

Check it out here: http://lists.freedesktop.org/archives/cairo/2011-February/021707.html

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.

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.

(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.