Crash in OOM | small on http://www.zpravy.cz/ on fennec

NEW
Assigned to

Status

()

P3
critical
2 years ago
9 months ago

People

(Reporter: skywalker333, Assigned: jnicol)

Tracking

({crash})

unspecified
Unspecified
Android
crash
Points:
---

Firefox Tracking Flags

(firefox53 wontfix, firefox54+ wontfix, firefox55+ wontfix, firefox56 affected, firefox57 affected)

Details

(crash signature)

Attachments

(1 obsolete attachment)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-f07ca18b-31aa-407d-9e72-d122a0170418.
=============================================================
(Reporter)

Comment 1

2 years ago
I am able to reproduce this crash on http://www.zpravy.cz/ by zooming in and out, scrolling, and rotating the display from portrait to landscape with Firefox for Android Beta 53.0b7.
Jamie, any thoughts here? I don't know if the "TextureUsage" metadata item in the crash report is actually measuring allocated texture usage but it seems pretty high.
Flags: needinfo?(jnicol)
(Assignee)

Comment 4

2 years ago
I think that's allocated gl texture size in bytes, which is indeed high. The page is creating lots of painted layers. I will investigate why.
Assignee: nobody → jnicol
Flags: needinfo?(jnicol)
Priority: -- → P3
(Assignee)

Comment 5

2 years ago
Created attachment 8862923 [details]
testcase.html

Attached is a minimal test case reproducing the problem.

The timestamp for each article uses background-attachment:fixed to render the gradient beneath the text. As I understand it this means that the Background display items should be fixed to the viewport but their clip should scroll with the main page. So FrameLayerBuilder adds the page's scrollable content (headlines, images,etc) to a PaintedLayerDataNode, then encounters a timestamp. The timestamp has a different AGR, so FrameLayerBuilder must finalise the Node which was in progress. Then it continues building another layer until it reaches another timestamp and must finalise that layer too. This results in far too many layers, causing high memory usage.

I think FrameLayerBuilder should be smart enough to realise that since the clip scrolls, the timestamps do not interfere with the layerisation of the page. It should pretend that it has the same AGR as the scrollable content. There is code for this in ProcessDisplayItems(). On desktop this happens, but on android it does not. I'm trying to figure out why.
(Assignee)

Updated

2 years ago
Summary: Crash in OOM | small → Crash in OOM | small on http://www.zpravy.cz/ on fennec
(Reporter)

Updated

2 years ago
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
(Reporter)

Updated

2 years ago
See Also: → bug 1361354
(Assignee)

Comment 6

2 years ago
Comment on attachment 8862923 [details]
testcase.html

My description in comment 5 isn't quite accurate, and the test case as wrong. The clipping was working correctly for the first 20 fixed positions. But once the layers.max-active limit was reached the fixed position backgrounds start to be rendered using inactive layers, which are not clipped correctly. This leads to the excessive layerization because of something similar to the reason described.

This was fixed in bug 1358185.

There is still a large issue, however: We need to be able to composite the correct parts of the background as the page is async scrolled. To do this each background is rendered in to a layer the size of the viewport. There are a lot of items with fixed position backgrounds, so this requires a very large amount of memory.
Attachment #8862923 - Attachment is obsolete: true
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

per https://bugzilla.mozilla.org/show_bug.cgi?id=1041968#c37
tracking-firefox54: --- → ?
tracking-firefox55: --- → ?
Flags: needinfo?(gchang)
Track 54+/55+ as the volume of crashes is high.
tracking-firefox54: ? → +
tracking-firefox55: ? → +
Flags: needinfo?(gchang)
Mark 54 won't fix as 54 was released.
status-firefox53: affected → wontfix
status-firefox54: affected → wontfix
(Reporter)

Updated

a year ago
status-firefox56: --- → affected
status-firefox55: affected → wontfix
(Reporter)

Updated

a year ago
Has STR: --- → yes
status-firefox57: --- → affected
(Assignee)

Updated

9 months ago
See Also: → bug 1418816
You need to log in before you can comment on or make changes to this bug.