Closed Bug 739159 Opened 13 years ago Closed 10 years ago

Loading very large images causes Fennec to crash (OOM)

Categories

(Core :: Graphics: ImageLib, defect, P5)

ARM
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking-fennec1.0 --- -
fennec + ---

People

(Reporter: AdrianT, Unassigned, Mentored)

References

()

Details

(Keywords: crash, Whiteboard: [native-crash][oom])

Attachments

(1 file)

Attached file logs when opening the link (deleted) —
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.
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.
Keywords: crash
Whiteboard: oom
Whiteboard: oom → [native-crash][oom]
blocking-fennec1.0: --- → ?
Version: Firefox 14 → Trunk
tracking-fennec: --- → +
blocking-fennec1.0: ? → -
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?
Flags: needinfo?(adrian.tamas)
Still an instant OOM crash on these images as they are being directly linked. Thus won't get deferred by bug 689623.
Flags: needinfo?(adrian.tamas)
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.
Component: General → ImageLib
Product: Firefox for Android → Core
Whiteboard: [native-crash][oom] → [native-crash][oom][mentor=snorp]
Mentor: snorp
Whiteboard: [native-crash][oom][mentor=snorp] → [native-crash][oom]
filter on [mass-p5]
Priority: -- → 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.
Summary: Loading very large images causes Nightly to run OOM → Loading very large images causes Fennec to crash (OOM)
(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.
Flags: needinfo?(rnewman)
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(rnewman)
Resolution: --- → FIXED
Depends on: 1060869
No longer depends on: 739245
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: