STEPS TO REPRODUCE: 1. Open two (or more) tabs. 2. In one tab, open this URL: http://veimages.gsfc.nasa.gov/7100/world.topo.bathy.200401.3x21600x21600.B2.png 3. As soon as firefox displays the name of the image in the titlebar (after ~1 second depending on connection speed), close the tab. (Or: Hit 'Esc' key or stop button) ACTUAL RESULTS: After step 3... - Firefox becomes unresponsive. - Xorg spikes to consume ~100% CPU and ~50% memory, according to 'top' (I have 6 gigs of RAM) - After ~5 seconds, system becomes almost completely unresponsive until you manage to kill firefox EXPECTED RESULTS: System should remain responsive; xorg shouldn't suddenly gobble all your memory. NOTE: You can actually wait quite a while to perform step 3, and everything's basically fine while you wait. As the image slowly appears, Firefox does take up a good chunk of memory and Xorg takes up a lot of CPU, but everything else remains normal. (In particular, Xorg's memory usage remains at less than 1%.) However, as soon as you interrupt the image-load, Xorg's memory usage spikes and you enter system-unresponsiveness-hell. (as Xorg starts paging, presumably)

Reporting with: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre WORKSFORME in Firefox 3.6: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14pre) Gecko/20101207 Namoroka/3.6.14pre In 3.6, as soon as I hit Esc/stop, the image is replaced with the text "The image [url] cannot be displayed, because it contains errors." and Firefox/Xorg return to their resting states. (Everything's ok if I interrupt it by closing the tab, too.)

Regression range: 20100912030140 cd3c926a7413 20100913030801 84ee6bc0484d http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cd3c926a7413&tochange=84ee6bc0484d Sadly, that was a big day for imagelib changes. :) My first suspect, however, would be: http://hg.mozilla.org/mozilla-central/rev/508d0a50827c "Bug 595055 - Use the correct context when deleting textures, so we don't accidentally unset some state like the viewport. r=vlad a=b"

Narrowed regression range a bit with targeted local builds -- it regressed from bholley's mega-push that day... http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=817a480e3836 ...and it regressed with a changeset *after* 817a480e3836.

Looks like it's a regression from this changeset: http://hg.mozilla.org/mozilla-central/rev/342e9263a73d "Bug 514033 - Error recovery for imagelib - part 11 - Move error-case teardown notifications into Decoder::Finish(), and call it unconditionally.r=joe,a=blocker" A build from that cset is affected by this bug, whereas a build from its parent (af4885147126) is unaffected (behaves like Firefox 3.6).

Requesting blocking since (a) this is a regression with respect to Firefox 3.6 that can cause your system to lock up. (b) it regressed from a changeset that wasn't intended to have much of a functional change (IIUC)

This is a regression, but I'm not 100% convinced it's a common enough usecase to block the release of 4.0. I plan to look at this though.

Firefox eating all RAM needlessly is a DoS - security issue. This could be probably triggered programatically in a site's JavaScript leading to DoS on Firefox visitors.

(In reply to comment #6) > This is a regression, but I'm not 100% convinced it's a common enough > usecase to block the release of 4.0. It may not be a super-common use-case, but it's definitely not niche behavior. (Say, you load a large image like a hi-res photo from your camera, then you realize that it's slow and/or huge so you stop the loading, and *bam* your system is unusable.) And the effects are super-bad - system hang, rather than just firefox hang.

> but it's definitely not niche behavior. (sorry, I might have been exaggerating there - I'm not sure what the image-size threshold is where this becomes a problem, but it may only be for veryvery large images. I think the original image here might've been >100MB (though I can't connect to its server at the moment.))

The other problem is that you can't know the size of the image in advance so it is technically possible to craft an attack targeted at Firefox users by providing a link (or including an image inline) in some forum or wherever such links could be expected. The image need not use large amount of space on the server if it's all black and compressed.

The URL in comment 0 is no longer valid ("Firefox can't find the server at veimages.gsfc.nasa.gov"), but it looks like the same image is available here: http://eoimages.gsfc.nasa.gov/images/imagerecords/73000/73580/world.topo.bathy.200401.3x21600x21600.B2.png I can't reproduce this bug using that URL, with current Nightly (on 64-bit Ubuntu 14.10). No hang, no memory-gobbling. 38.0a1 (2015-01-21) Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Closing this as WFM.

I didn't see this bug until now but similar bugs along these lines were fixed by bug 1060869. That's almost certainly the case here too.