This bug was filed from the Socorro interface and is report bp-f07ca18b-31aa-407d-9e72-d122a0170418. =============================================================
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.
Do these help? Report ID Date Submitted bp-0165acf3-c6b6-4efc-aa4a-8593c0170418 04/18/2017 05:21:45 bp-59900f99-83f8-4b1b-aa3a-568920170418 04/18/2017 05:20:20 bp-7ef53d60-9188-452f-8b31-88d9a0170418 04/18/2017 05:17:22 bp-2afbc08a-b1a0-4ab8-af59-fd3250170418 04/18/2017 05:17:08 bp-0bfd0d2f-0144-4aa9-bb17-17ebd0170418 04/18/2017 05:15:01 bp-f07ca18b-31aa-407d-9e72-d122a0170418 04/18/2017 05:00:52 bp-e2a8a25d-d2b2-4776-ba58-397050170418 04/18/2017 05:00:34 bp-f7801a44-6e83-4c06-9763-3c4760170418 04/18/2017 04:52:02 bp-bb7e30b8-6106-4510-85b4-cb4010170418 04/18/2017 04:49:57 bp-44d569e5-bad4-4738-8a9e-6b3b30170418 04/18/2017 04:36:35 bp-100a03ff-93c6-4f9d-86ce-a45a90170418 04/18/2017 04:36:08 bp-b860229d-2fc9-476a-8659-f18fc0170418 04/18/2017 04:35:27 bp-17d49fff-4cb6-4838-9dc8-315b10170418 04/18/2017 04:34:53 bp-ef7f271d-ba68-4284-a019-980f80170418 04/18/2017 04:33:58 bp-9dffd053-9d91-4391-9ccb-c569a0170418 04/18/2017 04:33:43 bp-93566be4-f276-4d7c-9ece-56e310170418 04/18/2017 04:11:07
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
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.
Summary: Crash in OOM | small → Crash in OOM | small on http://www.zpravy.cz/ on fennec
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox55: --- → affected
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: --- → ?
Track 54+/55+ as the volume of crashes is high.
tracking-firefox54: ? → +
tracking-firefox55: ? → +
Mark 54 won't fix as 54 was released.
status-firefox53: affected → wontfix
status-firefox54: affected → wontfix
You need to log in before you can comment on or make changes to this bug.