assertion failed: self.font_contexts.lock_shared_context().has_font(&font.font_key)
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | disabled |
firefox-esr78 | --- | disabled |
firefox-esr91 | --- | wontfix |
firefox65 | --- | wontfix |
firefox66 | --- | wontfix |
firefox67 | --- | wontfix |
firefox68 | --- | wontfix |
firefox69 | --- | wontfix |
firefox70 | --- | wontfix |
firefox71 | --- | wontfix |
firefox72 | --- | wontfix |
firefox76 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
firefox79 | --- | wontfix |
firefox80 | --- | wontfix |
firefox81 | --- | wontfix |
firefox82 | --- | wontfix |
firefox91 | --- | wontfix |
firefox92 | --- | wontfix |
firefox98 | --- | wontfix |
firefox99 | --- | fixed |
People
(Reporter: tsmith, Assigned: lsalzman)
References
(Blocks 3 open bugs)
Details
(4 keywords, Whiteboard: [tbird crash])
Crash Data
Attachments
(2 files, 1 obsolete file)
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
Updated test case.
Reporter | ||
Comment 2•5 years ago
|
||
Please let me know if a Pernosco session would be helpful and I will create one.
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 6•5 years ago
|
||
The crash spike with this signature in nightly was fixed in bug 1640401.
Reporter | ||
Comment 7•4 years ago
|
||
The attached test case no longer reproduces this issue.
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Some signatures with this crash reason even mention DejaVuSans.ttf, NotoSansCJK-Bold.ttc, NotoSansCJK-Regular.ttc, NotoSansCJK-Thin.ttc.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Fonts are added asynchronously to the shared context via async_for_each
1. I don't see a mechanism to ensure that this it will happen before the frame_building code starts requesting glyphs. So it could be a race condition.
One way to work around it is (A) to change async_for_each to be a bit less async and do the shared_context work on the calling thread. We'd pay the overhead of adding/deleting fonts on the render backend thread but at least add_font would be guaranteed proper ordering with respect to request_glyph.
The other thing we could do (B) is to not have this assertion in request_glyph, and panic when rasterizing the glyph instead. It would not add any overhead but if the bug isn't the race condition I described, then it will move the signature which gets in the way of tracking and solving it.
I propose that we first do (A), at the risk of taking a perf hit and see if it fixes the crash. If it does and the regression is worse than what we're comfortable with, then we can do (B).
Comment 13•4 years ago
|
||
Actually I think that we are protected by blocking the calling thread until all font contexts have been locked in https://searchfox.org/mozilla-central/rev/27932d4e6ebd2f4b8519865dad864c72176e4e3b/gfx/wr/webrender/src/glyph_rasterizer/mod.rs#870
So that would rule out the race condition I mentioned earlier.
Comment 14•4 years ago
|
||
Next idea: If a font fails sanitization, WebRender doesn't know about it. Perhaps we should have a special placeholder added for fonts that faild sanitization, if only to have more context when failing to request the glyphs.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
Seeing this with Thunderbird. All linux https://crash-stats.mozilla.org/signature/?product=Thunderbird&signature=webrender%3A%3Aprepare%3A%3Aprepare_interned_prim_for_render&date=%3E%3D2021-06-11T08%3A43%3A00.000Z&date=%3C2021-09-11T08%3A43%3A00.000Z
Assignee | ||
Comment 16•3 years ago
|
||
WebRenderBridgeChild::GetFontKeyForScaledFont can currently cause a IpcResourceUpdateQueue race.
If we're in the middle of a transaction building a blob image, GetFontKeyForScaledFont is called
in the blob image building code using the transaction's IpcResourceUpdateQueue as expected, such
that resource updates are sent out when the transaction is finalized.
However, TextDrawTarget calls into PushGlyphs without passing along its IpcResourceUpdateQueue,
calling GetFontKeyForScaledFont without it, and causing it to immediately send out the resource
update.
So if a blob image uses a font key and submits a resource update, but a display list is built
after that also using the font key within the transaction, the display list will fail to send
the resource update because it thinks the blob image already did, even though the blob image
transaction has not yet been finalized.
The simple fix is to just pass IpcResourceUpdateQueue from TextDrawTarget into PushGlyphs, thus
ensuring the resource updates are properly ordered.
Updated•3 years ago
|
Comment 17•3 years ago
|
||
Comment 18•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 19•3 years ago
|
||
== Change summary for alert #33534 (as of Tue, 15 Mar 2022 13:11:18 GMT) ==
Improvements:
Ratio | Test | Platform | Options | Absolute values (old vs new) |
---|---|---|---|---|
7% | linkedin ContentfulSpeedIndex | macosx1015-64-shippable-qr | cold fission webrender | 1,930.79 -> 1,803.75 |
6% | linkedin ContentfulSpeedIndex | macosx1015-64-shippable-qr | cold fission webrender | 1,913.67 -> 1,806.00 |
4% | google-slides ContentfulSpeedIndex | linux1804-64-shippable-qr | cold fission webrender | 1,257.96 -> 1,212.67 |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33534
Updated•3 years ago
|
Updated•3 years ago
|
Description
•