Closed Bug 1478084 Opened Last year Closed Last year

Crash in _cairo_user_data_array_set_data.cold.16


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

Not set



Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 --- fixed


(Reporter: calixte, Assigned: lsalzman)


(Blocks 2 open bugs)


(Keywords: crash, regression)

Crash Data


(2 files)

This bug was filed from the Socorro interface and is
report bp-394c6ef7-a809-4f76-88dd-2ce150180724.

Top 10 frames of crashing thread:

0 _cairo_user_data_array_set_data.cold.16 
1 mozilla::gfx::ScaledFontFontconfig::CreateFromInstanceData gfx/2d/ScaledFontFontconfig.cpp:466
2 mozilla::gfx::UnscaledFontFontconfig::CreateScaledFont gfx/2d/ScaledFontFontconfig.cpp:374
3 mozilla::gfx::RecordedScaledFontCreationByIndex::PlayEvent const gfx/2d/RecordedEventImpl.h:3292
4 mozilla::gfx::RecordedEvent::DoWithEvent<mozilla::gfx::InlineTranslator::TranslateRecording> > gfx/2d/InlineTranslator.cpp:84
5 mozilla::gfx::InlineTranslator::TranslateRecording gfx/2d/InlineTranslator.cpp:89
6 mozilla::wr::Moz2DRenderCallback gfx/webrender_bindings/Moz2DImageRenderer.cpp:323
7 wr_moz2d_render_cb gfx/webrender_bindings/Moz2DImageRenderer.cpp:369
8 rayon::iter::plumbing::bridge_producer_consumer::helper gfx/webrender_bindings/src/
9 <rayon_core::job::StackJob<L, F, R> as rayon_core::job::Job>::execute third_party/rust/rayon/src/iter/plumbing/


There is 1 crash in nightly 63 with buildid 20180723100101. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1455422.

Flags: needinfo?(nical.bugzilla)
Thoughts Lee?
Flags: needinfo?(lsalzman)
The Cairo font user data array is unfortunately not thread safe. In principle we had previously locked most places that could simultaneously muck with the same font's user data, but it's possible that as a result of the aforementioned bug 1455422 maybe we are now hitting a path that is not properly locking things. I'll try to dig a bit.
Flags: needinfo?(lsalzman)
This ensures we're holding the unscaled font's mutex while we mess with any font face user data. To do this it just exposes some backend hooks for locking and unlocking.

In some cases there are some cairo_ft_font_faces that don't remember their unscaled font anymore, not allowing the locking hooks to work, so we need to instead just lock the mutex around the call to cairo_font_face_destroy in those places.
Assignee: nobody → lsalzman
Attachment #8994972 - Flags: review?(jmuizelaar)
There is one place where this new internal locking inside cairo_font_face_set_user_data can cause us to recursively lock if we're already inside the scope of cairo_ft_scaled_font_lock_face.

However, in the one instance, we don't actually need to pass a valid SkFontStyle to Skia, since SkFontHost_cairo doesn't use any of that. So we can just get rid of the cairo_ft_scaled_font_lock_face call here and all is well.
Flags: needinfo?(nical.bugzilla)
Attachment #8994973 - Flags: review?(jmuizelaar)
Attachment #8994972 - Flags: review?(jmuizelaar) → review+
Attachment #8994973 - Flags: review?(jmuizelaar) → review+
Pushed by
make cairo_font_face_set_user_data thread-safe. r=jrmuizel
fix recursive locking in SkFontHost_cairo. r=jrmuizel
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Duplicate of this bug: 1478577
You need to log in before you can comment on or make changes to this bug.