1519833 - Crash in webrender::prim_store::PrimitiveStore::prepare_interned_prim_for_render

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

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

Top 10 frames of crashing thread:

0 libxul.so MOZ_CrashOOL mfbt/Assertions.h:314
1 libxul.so GeckoCrashOOL toolkit/xre/nsAppRunner.cpp:5105
2 libxul.so gkrust_shared::panic_hook toolkit/library/rust/shared/lib.rs:232
3 libxul.so core::ops::function::Fn::call libcore/ops/function.rs:78
4 libxul.so std::panicking::rust_panic_with_hook src/libstd/panicking.rs:480
5 libxul.so std::panicking::begin_panic libstd/panicking.rs:410
6 libxul.so webrender::prim_store::PrimitiveStore::prepare_interned_prim_for_render gfx/wr/webrender/src/glyph_rasterizer/no_pathfinder.rs:49
7 libxul.so webrender::prim_store::PrimitiveStore::prepare_prim_for_render gfx/wr/webrender/src/prim_store/mod.rs:2209
8 libxul.so webrender::prim_store::PrimitiveStore::prepare_primitives gfx/wr/webrender/src/prim_store/mod.rs:2266
9 libxul.so webrender::prim_store::PrimitiveStore::prepare_prim_for_render gfx/wr/webrender/src/prim_store/mod.rs:1969

=============================================================

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.

Comment 1

[Marcia Knous [:marcia]]

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).

Comment 2

[Darkspirit]

(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.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

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

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Here are a couple of urls where we're seeing the crash:

https://www.berlin-welcomecard.de/en/partner/flughafen-tempelhof-tempelhof-airport
http://www.fussball.de/spieltagsuebersicht/ewag-kamenz-liga-staffel-1-kreis-westlausitz-kreisliga-a-herren-saison1819-sachsen/-/staffel/02409LO38S000003VS54898EVUVF00VA-G#!/
https://svwestfalia03.de/fussball/1-mannschaft
https://twitter.com/menschenfracht
https://twitter.com/turbojedi/status/1116042796748759041

Comment 5

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 6

[Glenn Watson [:gw]]

A fix for the render task size crashes is https://bugzilla.mozilla.org/show_bug.cgi?id=1543844. 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.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 9

[Glenn Watson [:gw]]

Should this be closed now as fixed?

Comment 10

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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