Fennec/14.0a1 2012-03-23 Device: Motorola Droid 2 (Android 2.3)/ Google Nexus S ( Android 2.3.6) Steps to reproduce: 1. Go to: http://www.race.u-tokyo.ac.jp/~uchida/blogdata/dataset1_community_large.png ( shortlink goo.gl/IC0pn) 2. Wait for the image to load. - the image resolution is 8000x6000. Expected results: The page can be loaded or image fails to load without crashing Nightly. Actual results: The device runs out of memory and Nightly is closed. Notes: The issue is not reproducible on the Android Browser

The issue is reproducible on Nightly from 2012-03-25

This is probably won't-fix. Not sure what you're expecting from a mobile browser loading such resources from a device with low hardware too.

The issue is not reproducible on the same device on the Android Browser. Actually the Android Browser loads the image without any issues. From what I am seeing Fennec crashes when loading images with resolutions greater then ~4500 pixels. While I am not expecting the image to be loaded with limited resources I am expecting Fennec to anticipate that the device is running out of memory and prevent a crash. On an HTC Desire running Android 2.2 I even experienced a soft reset of the device.

bug 622816 ?

Related to bug 683284?

actually maybe bug 698298? bug 683284? Wonder if there's something we can do on Fennec end?

I guess bug 677727 is also related.

Still an issue on Firefox Mobile 15 beta 4 testing on Asus Transformer TF101 running Android 4.0.3. Tested using the link http://www.acooke.org/img/drawings/2005/mar/1/arms-10000.png

The issue is reproducible on Asus EEE Transformer TF101 (Android 4.0.3) on Firefox Mobile 18 beta 1 when loading http://www.guigoz.net/bric_a_brac/tilt_shift.jpg

Does it happen in today's nightly that contains the fix of bug 689623?

Still an instant OOM crash on these images as they are being directly linked. Thus won't get deferred by bug 689623.

This is still an issue on Firefox Mobile 21 beta 4 build 1 on the LG Optimus 2X (Android 2.2)

Seems like a png animation with many frames (800x600 pixelx256 frames is more than a average mobile device's memory can hold) can have the same effect. Reproducible with a Samsung Galaxy Note and the following URL: http://www.physikbuch.de/physik-erklaert/dunkle-materie/

This is really bug 622816 except on Android which has often very limited amount of memory this is really critical. Firefox needs to manage its memory consumption. When loading media that potentially requires lots of memory to load it should detect the amount of memory available and refuse to load media that would exhaust system resources. Of course, further optimization of the memory required to store the media by downsamling/storing only current frame/.. is useful for making more media available under limited resources. For that firefox needs to be aware of the limits, though.

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

filter on [mass-p5]

Am thinking: Would filling big chunks of memory with a png image containing losslessly compressed assembler code help defeating aslr and similar? On the other hand: If it actually does: What doesn't? Would it therefore make sense to look at the total size of all images of a page [in pixels] before attempting to uncompress them? A page with non-moving images that aren't this small while compressed but tend to be bigger than today's phone's memories currently is: http://www.physikbuch.de/typo3temp/tx_ncstaticfilecache/www.physikbuch.de//absurde-phaenomene/drei-sonnen.html/

...or better: Would it make sense to check if the memory is big enough before attempting to uncompress an image? The current IE caches the compressed versions of all images but throws away the uncompressed version of big images as soon as they no more are on the screen. With the page form above this happens even if there still is plenty of memory left.

(In reply to Gunter Königsmann from comment #20) > ...or better: Would it make sense to check if the memory is big enough > before attempting to uncompress an image? We do. We are much harsher about this on Nightly than we used to be, as well. (Unfortunately, I don't have a resource-constrained Android device at the moment, or I'd check, but I think it's quite possible this is fixed on Nightly.) > The current IE caches the compressed versions of all images but throws away > the uncompressed version of big images as soon as they no more are on the > screen. With the page form above this happens even if there still is plenty > of memory left. We do the same thing IE does. If this is still not fixed on Nightly, I'd guess that what's happening is that ImageLib gets the system *close* to OOM, and then another piece of code tries to allocate and fails to handle the allocation failure, triggering a crash. On my Android tablet (which has several GB of RAM and thus isn't great for testing this bug) I could only reproduce with the STR in comment 14. Those STR triggered bug 760394 for me - which, it is worth noting, seems to be a crash due to OOM at the Java layer, nowhere near ImageLib.

Richard, could you please check the STR in comment 1 in a current Nightly on a low-memory Android device? (512MB or lower) What I would expect is that the comment 1 STR is no longer reproducible, but the comment 14 STR is. That's because memory for animated and non-animated images is currently managed very differently. If the comment 1 STR no longer reproduces, I'd like to resolve this bug and file a new bug for the comment 14 STR.

Sorry. I just came back from vacation, and my brain is still waking up. In comment 22, when I tested the STR in comment 14, I tested it in *release* Firefox for Android by mistake. I just tested it in Nightly, and on my tablet I can't reproduce. That does not mean that it won't reproduce on low-memory Android devices, though. Richard, could you check that one too? I still think that the comment 1 STR won't reproduce, even on low-memory Android devices. I'm now not sure one way or the other about the comment 14 STR. The good news is that I have a patch already written, but not uploaded to Bugzilla yet, that will make us manage memory for animated and non-animated images in the same way. I'd expect that, if the comment 14 STR *do* still reproduce on low-memory Android devices, that patch will solve it.

I tested a current fx-team build on a Cubot device (Android phone running Android 4.4 but only 256MB of RAM). Comment 1 Link: Displays an error "The image '<url>' cannot be displayed because it contains errors." Comment 14 Link: Fully loads the page, then crashes.

Thanks for testing, Mark! (In reply to Mark Finkle (:mfinkle) from comment #25) > Comment 1 Link: Displays an error "The image '<url>' cannot be displayed > because it contains errors." Nice! That means that the original subject of this bug is fixed - simply loading a large image will not cause us to crash. Even though they seem similar, animated images are a different case and deserve a separate bug. I'm going to file a new one and post Gunter's STR there. This bug can be resolved.

Gunter, Mark, and anyone else who may be interested: I just filed bug 1116359 about the animated image case. We'll track work on fixing the problem there.