Created attachment 722500 [details] Log of Pinterest's attempt to load Repro steps: 1. From the homescreen, swipe to the right to load Everything.me 2. Select Social, then Pinterest. 3. Observe the page as it loads. Expected: Pinterest loads with no errors. Actual: The page attempts to load, but crashes after about 10-15 seconds. Repro rate: 100% at first, but will decrease with multiple attempts to access the site. Unagi build 20130307103636 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a0b06192f882 Gaia: fa5245750e7bb94b9f64180967536509316dedf5 Kernel Date: Dec 5
Severity: normal → critical
Hi, I've checked the app called Pinterest on the FFox device we have and the app works fine here.
does it still happen on your Unagi?
Assignee: nobody → gur
I no longer see OOM (Out Of Memory) errors as of Unagi build 20130312070202 just by launching Pinterest. However, selecting an image on the page and exiting after the next page loads would cause an OOM error when the user exits. Sometimes the user doesn't even have to exit out, the app will exit on its own. However, I'm not sure that this would be Pinterest's fault since the next pages tend to go to different sites (eg www.necessaryclothing.com or www.upgradereality.com). Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/99680a32f297 Gaia: de3e5b9205e6cb1a6bd0858a98d159272ad96d11 Kernel Date: Dec 5
OOM issue reproduces on Unagi Commercial RIL with the following: Build ID: 20130321070203 Kernel Date: Dec 5 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/7508c5a1026b Gaia: 7af427d35c4d557c75b2060022815f07851acc28
Comment 3, issue occurs on both Mozilla and Commercial RIL Request escalation to P2
blocking-b2g: --- → leo?
Is 1.0.1 also affected? If so this might be a TEF? instead.
It's really bad with 1.0.1, Pinterest doesn't even have a chance to load before the user is kicked back to the homescreen. Tested with the latest stable build, version 20130313070202 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/e74dafa6b2d9 Gaia: b34e726147f8e671ad8c538b50900ccfbffcb084 Kernel Date: Dec 5
Still repros on Unagi version 20130404070202 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/da523063aa7b Gaia: a845be046c5d3cb077e3c78f963ca5c079e7ab3d Kernel Date: Dec 5 The user will OOM on exiting Pinterest, and also if the user scrolls down the page enough. The app will keep loading more images until the user is sent back to the homescreen.
I'm not sure how this goes, but if it's really an OOM issue- does removing the app really the best solution? I mean, I'm sure there will be more apps that will cause memory issues, since many load images as their main thing. Of course we can remove it, but we risk losing a lot of high-value content. Shouldn't this be solved on the browser/gecko level, with better garbage collecting?
Created attachment 741277 [details] about:memory taken after opening Pinterest I've succeeded in capturing a memory report right after the application started. This was done on a Unagi with today's v1-train engineering build. As you can see there's 73+ MiB worth of images in the dump. ~6 MiB contain the compressed images and there's a whopping ~67 MiB of uncompressed ones (i.e. in use on the page). I've inspected http://m.pinterest.com/popular with the desktop browser and what seems to be happening is that they're loading huge images in the main page (one alone is ~2.5 MPix so ~10 MiB uncompressed). There's not much we can do here, the problem is entirely on their side.
The main problem is that we eagerly fire of almost a hundred image decode requests as the images are added to the document and we lock them into place. That can't work. Bug 862970 fixes both. We no longer lock images and we only eagerly decode some number (24) and then decode the rest as needed. Newly decoded images can throw older images out of memory (I set the limit to 30MB of decoded images). Gabriele, can you try my patch and confirm that this works? I also have a test case in the other bug.
(In reply to Andreas Gal :gal from comment #12) > The main problem is that we eagerly fire of almost a hundred image decode > requests as the images are added to the document and we lock them into > place. That can't work. Yeah, in this case we're loading 15MPixels worth of images and keeping them around which makes memory consumption of the app skyrocket. > Bug 862970 fixes both. We no longer lock images and > we only eagerly decode some number (24) and then decode the rest as needed. > Newly decoded images can throw older images out of memory (I set the limit > to 30MB of decoded images). Gabriele, can you try my patch and confirm that > this works? I also have a test case in the other bug. I'll try it right away and report back. If your patch fixes the problem shall we close this bug as a duplicate?
I've justed tested with the patch from bug 862970 applied and it fixes the problem. RSS for the process is now ~50MiB when I open Pinterest (it used to be north of 100MiB) and never goes over 70MiB even while quickly scrolling towards the bottom to make it pull more images from the feed. Before applying the patch scrolling would almost immediately cause the app to go OOM and be killed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
No longer depends on: 862970
Resolution: --- → DUPLICATE
Verifying Works For Me, issue appears to have been fixed in bug 862970. Issue no longer reproduces in the latest v1.0.1 Pinterest loads, and can be scrolled through without crashing
Status: RESOLVED → VERIFIED
Resolution: DUPLICATE → WORKSFORME
Please do not undupe bugs that are correctly marked. If you are doing a verification, please go off of the duped bug.
Status: VERIFIED → RESOLVED
Last Resolved: 6 years ago → 6 years ago
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.