889966 - [B2G] [Browser] Crash upon using lots of 3d transformed layers because of out of memory

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Sotaro Ikeda [:sotaro]]

+++ This bug was initially created as a clone of Bug #877495 +++

Description:
When the user taps on the molecule links, the browser crashes (Crash report links provided in the notes). 

Repro Steps:
1. Updated to Leo Build ID: 20130529070208
2. Launch Browser app
3. Go to http://bit.ly/css3d-mol
4. Select any of the links at the bottom of the page (Caffine, Salt, Buckyball or Graphite)

Expected: Browser displays 3D images of the molecule

Actual: Browser Crashes

Comment 1

[Sotaro Ikeda [:sotaro]]

Bug 877495 handles crash because of hit file descriptor limit. This bug handles the crash because of out of memory.

Comment 2

[Sotaro Ikeda [:sotaro]]

It is not clear that we can fix this for v1.1 because of the time limitation.

Comment 3

[Benoit Girard (:BenWa)]

Note that bug 873378 wont solve this by itself. 3D transformed as forced active layers. My patch only caps non-forced active layers. We don't have a transformation path for 3D transforms outside the compositor.

Comment 4

[Nicolas Silva [:nical]]

What is the good way to work around cases where web content require more memory than what the device can handle? Is it acceptable to skip images that we could not allocate and have incomplete rendering but without crashing?

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Is this a duplicate of 894037?

Comment 6

[Sotaro Ikeda [:sotaro]]

(In reply to Milan Sreckovic [:milan] from comment #5)
> Is this a duplicate of 894037?

It seems not a duplicate. In 894037, the browser tab process is not killed by low memory killer.

Comment 7

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #6)
> (In reply to Milan Sreckovic [:milan] from comment #5)
> > Is this a duplicate of 894037?
> 
> It seems not a duplicate. In 894037, the browser tab process is not killed
> by low memory killer.

But I can not reproduce Bug 894037 on master hamachi. Always get killed by low memory killer.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Gralloc / layers dump at the time of the out-of-pmem condition, using patch from bug 916626

This shows what's in gralloc buffers, and the layers tree, at the time when we run out of pmem.

Comment 9

[Preeti Raghunath(:Preeti)]

Milan is still working on this bug.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's run under the assumption this is a duplicate of bug 894037, despite comment 6, but because of comment 7.

Comment 12

[Alex Keybl [:akeybl]]

This was punted from 1.1, and we're now down to only landing critical blockers. Let's consider for 1.3.

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

Benoit, could you check if this problem still exists?

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

I checked today a current b2g-master build on hamachi. All works. I tried the molecules mentioned in comment 0: caffeine, salt, buckyball, graphite. All load and animate (albeit not very fast). No OOM anymore.

One performance warning though: framerate is about 1 fps, and the draw-fps counter is consistently above 800% overpainting.

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: about-memory dump

Extract with tar xfj, and then point your desktop firefox to this address:

about:memory?file=/path/to/about-memory-30/memory-reports

(replace /path/to by appropriate path)

Comment 16

[Benoit Jacob [:bjacob] (mostly away)]

Filed bug 951178 about the 800% overpainting.