1608722 - Crash in [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | gkrust_shared::oom_hook::hook | std::alloc::rust_oom | webrender_api::display_list::DisplayListBuilder::with_capacity]

Status: RESOLVED DUPLICATE of bug 1531819

(Core :: Graphics: WebRender, defect, P3)

Description

[[:philipp]]

This bug is for crash report bp-067b9495-e6b4-4ee5-9be6-53eee0200112.

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:197
3 xul.dll std::alloc::rust_oom src/libstd/alloc.rs:216
4 xul.dll alloc::alloc::handle_alloc_error src/liballoc/alloc.rs:248
5 xul.dll static webrender_api::display_list::DisplayListBuilder::with_capacity gfx/wr/webrender_api/src/display_list.rs:813
6 xul.dll webrender_bindings::bindings::wr_state_new gfx/webrender_bindings/src/bindings.rs:2301
7 xul.dll mozilla::wr::DisplayListBuilder::DisplayListBuilder gfx/webrender_bindings/WebRenderAPI.cpp:886
8 xul.dll mozilla::layers::WebRenderLayerManager::EndTransactionWithoutLayer gfx/layers/wr/WebRenderLayerManager.cpp:301
9 xul.dll nsDisplayList::PaintRoot layout/painting/nsDisplayList.cpp:3171

this oom crash signature is starting to appear in firefox 73 - so far exclusively from 64bit users on windows 10.

Comment 1

[Bert Peers [:bpeers]]

Allocation details in the crash report don't seem particularly high, and has some headroom:

Available Virtual Memory 138,530,549,272,576 bytes (138.53 TB)
Available Page File 187,658,240 bytes (187.66 MB)
Available Physical Memory 1,816,526,848 bytes (1.82 GB)

Miko, do you see anything suspicious that would suggest perhaps a corrupt DisplayList asking for enormous amounts of memory or somesuch? Thanks.

Comment 2

[Miko Mynttinen]

The crash reports seem to have different reported memory allocations ranging from 400KB to 12MB, with the most common sizes being 401.41KB and 802.82KB.
Assuming this is correct, the root cause is probably something else than the allocation itself.

Comment 3

[[:philipp]]

this signature first started showing up on nightly 73.0a1 build 20191211094640 and fairly frequently afterwards. anything in this range that looks related?:
*https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2019-12-10&tochange=f83f2771414cf5938a46f44e1b11cdcd5181ea0f
*https://mzl.la/2uMCShu

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Miko, does anything in that regression range stand out? These crashes are still showing up and we're getting late in the Fx73 Beta cycle, so please feel free to redirect if you're unsure.

Comment 5

[Miko Mynttinen]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #4)

Miko, does anything in that regression range stand out? These crashes are still showing up and we're getting late in the Fx73 Beta cycle, so please feel free to redirect if you're unsure.

I cannot spot anything obvious. It seems that Rust PGO was enabled for non-linux64, which might change code behavior on Windows somehow, but this is just a guess.

Jeff, any ideas?

Comment 6

[Jeff Muizelaar [:jrmuizel]]

I suspect this is just a dup of bug 1531819 and the PGO change changed the signature.