This bug is for crash report bp-15a34c81-2033-43ea-9912-0bb710200708.

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 xul.dll gkrust_shared::oom_hook::hook toolkit/library/rust/shared/lib.rs:115
3 xul.dll std::alloc::rust_oom ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/libstd/alloc.rs:240
4 xul.dll alloc::alloc::handle_alloc_error ../4fb7144ed159f94491249e86d5bbd033b5d60550//src/liballoc/alloc.rs:268
5 xul.dll static webrender_api::display_list::DisplayListBuilder::with_capacity gfx/wr/webrender_api/src/display_list.rs:1017
6 xul.dll webrender_bindings::bindings::wr_state_new gfx/webrender_bindings/src/bindings.rs:2212
7 xul.dll mozilla::wr::DisplayListBuilder::DisplayListBuilder gfx/webrender_bindings/WebRenderAPI.cpp:869
8 xul.dll mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:297
9 xul.dll nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:2382

@kats: Could you take a peek at this?

I don't know if there's much I can do here. The OOM is when allocating the space for the display list to send to WR, so it's a large-ish contiguous block of memory, the size of which is heavily dependent on the contents of the webpage. I looked at the crash reports in crash-stats and there's a variety of URLs. I tried loading a few but wasn't able to repro the crash. Maybe other people can try some of these URLs and see if they can repro; if so we can try to take a look at the display list and see if there's extraneous things in there that are causing bloat and can be removed.

Alternatively we can try and write code that catches the allocation failure and either bails out (so aborts the paint entirely, which will probably result in the user's view of the page not updating) or submits some sort of telemetry that gives us clues as to what to look for. e.g. number of display items or distribution of sizes in the display list.

Some URLs from crash reports:
https://pt.wowhead.com/item=163574/r%C3%A9deas-mastigadas-da-mula-de-carga-aterrorizada#english-comments
https://music.youtube.com/playlist?list=OLAK5uy_mkfqdyNpzFLKugcA5Oy7ZKoCv31o0bTZY
https://tradingdesk.finanzen.net/
https://www.facebook.com/groups/1242614559085818/?multi_permalinks=4604584926222081&notif_id=1593897359644720&notif_t=group_activity
https://biptik.com/
https://www.google.com/search?q=kennzeichen&client=firefox-b-d&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjQhLOw9L_qAhWloXEKHbhxCiQQ_AUoAXoECBIQAw&biw=1920&bih=910#imgrc=04TcWQhaU_dVcM
https://metabattle.com/wiki/Build:Scrapper_-_Explosive_Hammer

Miko, can you take a look?

(In reply to Jessie [:jbonisteel] pls NI from comment #3)

Miko, can you take a look?

This looks like bug 1531819, but with a new signature. I agree with Kats, it does not seem like we can do much here.

I tried opening one of the pages (metabattle.com), and checked the previous display list capacity, which was 401408 bytes. This is the same OOM allocation size as in this report1. Most reports seem to be some multiple of this size, which is probably due to how IPC bytebuf memory allocation works.

It is interesting that similar to other OOM issues we have such as bug 1541092, this too is only happening on Windows.