Closed Bug 1519833 Opened 6 years ago Closed 5 years ago

Crash in webrender::prim_store::PrimitiveStore::prepare_interned_prim_for_render


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




Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- fixed
firefox68 --- fixed


(Reporter: gsvelto, Assigned: gw)



(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-691efd21-8559-4b24-8a71-a63cb0190113.

Top 10 frames of crashing thread:

0 MOZ_CrashOOL mfbt/Assertions.h:314
1 GeckoCrashOOL toolkit/xre/nsAppRunner.cpp:5105
2 gkrust_shared::panic_hook toolkit/library/rust/shared/
3 core::ops::function::Fn::call libcore/ops/
4 std::panicking::rust_panic_with_hook src/libstd/
5 std::panicking::begin_panic libstd/
6 webrender::prim_store::PrimitiveStore::prepare_interned_prim_for_render gfx/wr/webrender/src/glyph_rasterizer/
7 webrender::prim_store::PrimitiveStore::prepare_prim_for_render gfx/wr/webrender/src/prim_store/
8 webrender::prim_store::PrimitiveStore::prepare_primitives gfx/wr/webrender/src/prim_store/
9 webrender::prim_store::PrimitiveStore::prepare_prim_for_render gfx/wr/webrender/src/prim_store/


There's just a handful of these crashes but they happen on both Linux and MacOS X with identical stack traces so they're probably a valid issue.

Changing platform to all since I see both Mac, Linux and Windows crashes. All have Moz Crash reason assertion failed: self.font_contexts.lock_shared_context().has_font(&font.font_key).

OS: Linux → All
Hardware: Unspecified → All
Priority: -- → P3

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #1)

All have Moz Crash reason assertion failed: self.font_contexts.lock_shared_context().has_font(&font.font_key).

First seen in bug 1425181. This bug just has a slightly different crash signature.

See Also: → 1425181

It looks like this is our top webrender related crash in release 66. It would be good if we can fix it for 67.

Assignee: nobody → gwatson
Blocks: wr-67
Flags: needinfo?(gwatson)
Priority: P3 → P2

It looks like the majority of these are caused by situations like:
"Attempting to create a render task of size 2048x16384". It feels like we should be able to figure out what's causing these big requests.

A fix for the render task size crashes is I opened a separate bug since this bug seems to have other crash traces in it too. But if that's not accurate, we could consider closing this when the linked bug lands.

Flags: needinfo?(gwatson)
No longer depends on: 1543844
Regressions: 1543844

Bug 1543844 is a fix for at least one of the root causes for this signature. It's not a regression from this bug. Adjusting relationship back.

Depends on: 1543844
No longer regressions: 1543844

Results so far are promising, in that there are no prepare_interned_prim_for_render crashes on 67.0b11. But it's still too early to claim success.

Blocks: wr-68
No longer blocks: wr-67

Should this be closed now as fixed?

Flags: needinfo?(kats)

Yeah, I guess. There seem to be a little trickle left but not sure if it's worth tracking at this point. If it goes back up in frequency we can file a new bug.

Closed: 5 years ago
Flags: needinfo?(kats)
Resolution: --- → FIXED

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.