[macOS 11 Beta] CoreText crash in call out of Skia fontstyle_from_descriptor()
Categories
(Core :: Graphics: Text, defect, P2)
Tracking
()
People
(Reporter: haik, Assigned: lsalzman)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release+
|
Details | Review |
This bug is for crash report bp-c47633a1-f292-4b9d-a59b-1f4ad0200805.
Top 10 frames of crashing thread:
0 libobjc.A.dylib libobjc.A.dylib@0x61dd
1 CoreGraphics CoreGraphics@0x8b7f5
2 CoreGraphics CoreGraphics@0x8b1fe
3 CoreText CoreText@0xbdbc4
4 CoreText CoreText@0xbdb27
5 CoreText CoreText@0x6f4a
6 CoreText CoreText@0x5966c
7 CoreText CoreText@0x14da7
8 CoreText CoreText@0x14c5d
9 CoreText CoreText@0x6a81
After upgrading to macOS Beta 4 (20A5343i), I've hit this crash twice within a about an hour. It appears to have started on August 4th when Beta 4 became available.
Updated•4 years ago
|
Updated•4 years ago
|
đź‘‹ Hi folks - just chiming in with a report that I too hitting this sporadically and repeatedly (8 times) since upgrading to Beta 4 yesterday. Seems to occur when clicking links or performing searches from the address bar - basically when loading a fresh page.
Here is one of the crash reports from my machine 60778d35-eef8-428b-ab4e-dfeb50200806.
Comment 4•4 years ago
|
||
This is a very frequent crash with the latest macOS Big Sur beta (beta 4). Lee, can you take a look at this?
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
Jonathan, are you able to look into this for me? My mac is non-functioning at the moment and I don't see any obvious reason why this is occuring.
Comment 6•4 years ago
|
||
Not really, sorry. Crashing so deep inside the system libs (and the correlation with a new OS beta coming out) looks to me like it's most likely an OS bug, but I'm not able to investigate directly -- I don't have a machine with Big Sur beta (maybe they should have called it Bug Sir?) here.
If someone can reproduce this at all reliably, catch it in a debugger, and identify what font skia is trying to use, that'd be a start.... but I'm not in a position to do that at the moment.
Comment 8•4 years ago
|
||
Markus, did you manage to install Big Sur? This issue is in dire need of somebody looking at it.
Marking as S2 for now.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
•
|
||
I put up a speculative workaround patch that people are welcome to try and see if it avoids the crashes. Circumstantial evidence points at this being an OS bug in their beta, as we don't really have much to go on. I don't have a Mac machine with Big Sur so I am unable to test myself.
Try builds here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=26f1bf6316bd81d2b694137a23e2c4523b6c00bf
Comment 11•4 years ago
|
||
Unfortunately I still don't have a Big Sur install. It's something I'll need to tackle soon.
Comment 12•4 years ago
|
||
I can try this out once the build is ready.
Comment 13•4 years ago
|
||
Okay used "OS X Cross Compiled debug" and it seems to be working fine refreshing gcal a lot which crashes the most for me on 79.
Comment 14•4 years ago
|
||
"OS X Cross Compiled shippable opt" is also working which convinces me the patch is sufficient.
Comment 15•4 years ago
|
||
I've got about an hour of dedicated usage logged on the "OS X Cross Compiled debug" artifact with no crashes yet. I'll keep running with this and report back.
Comment 16•4 years ago
|
||
Heh, and minutes after posting that I get a hard / full-browser crash. Might be unrelated? Here's the dump.
Comment 17•4 years ago
|
||
Yeah, that looks like an unrelated issue.
Comment 18•4 years ago
|
||
The Thread 18 Crashed:: WRWorker#0 stack looks like it might be in the vicinity?
Assignee | ||
Comment 19•4 years ago
|
||
It looks like webrender is creating the font in that case, meaning it doesn't have access to the Thebes workaround. So WR would apparently need a similar workaround if this is to work.
Comment 20•4 years ago
|
||
I notice there are a bunch of other threads that appear to be in the same area of code -- there are 6 of them all within CTFontDescriptorCopyAttribute in that report. I wonder if there's some kind of thread-safety bug in the system font code we're calling?
Reporter | ||
Comment 22•4 years ago
|
||
I have reached out to our Apple contact to see if this is a known issue with the Beta.
Assignee | ||
Comment 23•4 years ago
|
||
Assignee | ||
Comment 24•4 years ago
•
|
||
I put up a different variation of the patch that could be more of a silver bullet for this problem. It is probably the preferred workaround in the end if it works and if we need it. Inside Skia, we don't actually use their font selection at all, so providing any style information should hypothetically be superfluous, unless I managed to overlook something in the fine print of the code. This second patch should thusly side-step that by just passing in default font style for any font we create for Skia so that avoids querying the buggy CoreText API, regardless of where we create the font, WebRender or otherwise.
I have some try builds going for it: https://treeherder.mozilla.org/#/jobs?repo=try&revision=cbd15fb8e250c0d3a394991657c66059f118da85
Phinze, once those builds are ready, can you try them and see if they get rid of all issues for you?
Comment 25•4 years ago
|
||
Nice find on the new strategy, Lee!
I got a few hours worth of usage on the new build today with 0 crashes so far. I'll report back if I see anything fishy, but at this point it's looking good from here. đź‘Ť
Reporter | ||
Comment 26•4 years ago
•
|
||
Thanks! I've been running the fix all day on Nightly and haven't hit any crashes. I was hitting this more frequently on Release. Would the patch be valid for Release too? It applies cleanly.
Reporter | ||
Comment 27•4 years ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #26)
Thanks! I've been running the fix all day on Nightly and haven't hit any crashes. I was hitting this more frequently on Release. Would the patch be valid for Release too? It applies cleanly.
Sorry, right after I posted this comment I hit a few of these crashes with the patch. https://crash-stats.mozilla.org/report/index/60038701-e0f0-4b8c-8ef2-2489a0200811
Assignee | ||
Comment 28•4 years ago
|
||
Any way to get symbol information for that crash report? It is not easy to see what is going on from the addresses
Comment 29•4 years ago
|
||
I think there must be (at least) two different entry points to this crash. One (e.g. comment 0, comment 3) is via Skia's SkCreateTypefaceFromCTFont
and the fontstyle_from_descriptor
helper it uses, and the tentative patch here avoids this. But it looks to me like the call stack in comment 27 is somewhat different, although it ultimately crashes at the same place in Core Text / Core Graphics: the stacks match exactly as far as frame 8, but then the comment 27 stack indicates it has come there via a different path.
So my suspicion is that there's another entry point from Gecko (Skia?) into Core Text that can lead to hitting the same internal bug. Unfortunately there aren't any symbols telling us where that point is... :(
Reporter | ||
Comment 30•4 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #29)
So my suspicion is that there's another entry point from Gecko (Skia?) into Core Text that can lead to hitting the same internal bug. Unfortunately there aren't any symbols telling us where that point is... :(
I'm working on getting a stack trace.
Reporter | ||
Comment 31•4 years ago
|
||
Using the offsets from the crash report with the XUL object I was testing, here's the stack from https://crash-stats.mozilla.org/report/index/60038701-e0f0-4b8c-8ef2-2489a0200811 (from comment 27). Hope that helps.
XUL`create_from_CTFontRef:
XUL`SkCreateTypefaceFromCTFont:
XUL`mozilla::gfx::ScaledFontMac::CreateSkTypeface:
XUL`mozilla::gfx::ScaledFontBase::GetSkTypeface:
XUL`mozilla::gfx::DrawTargetSkia::DrawGlyphs:
XUL`mozilla::gfx::RecordedFillGlyphs::PlayEvent:
XUL`std::__1::__function::__func<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0, std::__1::allocator<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0>, bool (mozilla::gfx::RecordedEvent*)>::operator():
XUL`mozilla::gfx::RecordedEvent::DoWithEvent<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::MemReader>:
XUL`mozilla::gfx::InlineTranslator::TranslateRecording:
XUL`wr_moz2d_render_cb:
XUL`webrender_bindings::moz2d_renderer::rasterize_blob::h6787eeb41de8acba:
XUL`core::ops::function::Fn::call::h1ef12582558278a4:
XUL`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_mut::heb926afb0fefc8d7:
XUL`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_once::hb335592a447ff9af:
XUL`core::option::Option$LT$T$GT$::map::h5be409b13dcf33b9:
XUL`_$LT$core..iter..adapters..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h945d745a152b3aec:
XUL`rayon::iter::plumbing::Folder::consume_iter::hc5934a669c47bb93:
XUL`_$LT$rayon..iter..map..MapFolder$LT$C$C$F$GT$$u20$as$u20$rayon..iter..plumbing..Folder$LT$T$GT$$GT$::consume_iter::h2ce1de8952dcfc4c:
XUL`rayon::iter::plumbing::Producer::fold_with::h59fc95442ccd8a5b:
XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::h949aaa921f1e1a82:
XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::_$u7b$$u7b$closure$u7d$$u7d$::ha03b62b142491f2b:
XUL`rayon_core::join::join_context::call_a::_$u7b$$u7b$closure$u7d$$u7d$::h8e42927ce35c3541:
XUL`rayon_core::join::join_context::call_a::_$u7b$$u7b$closure$u7d$$u7d$::h8e42927ce35c3541:
XUL`std::panicking::try::do_call::hc3c7220546fbae1d:
XUL`std::panicking::try::h6f286088405f7626:
XUL`std::panic::catch_unwind::h2b371a79d4890314:
XUL`rayon_core::unwind::halt_unwinding::hc0412d2a103e7a16:
XUL`rayon_core::join::join_context::_$u7b$$u7b$closure$u7d$$u7d$::h50ecd8bdfe4d6c3b:
XUL`rayon_core::registry::in_worker::h26d2af5ff8b00c3a:
XUL`rayon_core::join::join_context::h24590f6b5d90b565:
XUL`rayon_core::join::join_context::h24590f6b5d90b565:
XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::_$u7b$$u7b$closure$u7d$$u7d$::he007b6784453c0d4:
XUL`rayon_core::join::join_context::call_b::_$u7b$$u7b$closure$u7d$$u7d$::h38243537e7de754a:
…
XUL`rayon_core::registry::main_loop::h2a1e112526114ec9:
XUL`rayon_core::registry::ThreadBuilder::run::h2059535dc8f33bf8:
XUL`_$LT$rayon_core..registry..DefaultSpawn$u20$as$u20$rayon_core..registry..ThreadSpawn$GT$::spawn::_$u7b$$u7b$closure$u7d$$u7d$::h2e7a5fbfa4c36d67:
…
XUL`std::sys::unix::thread::Thread::new::thread_start::hcced3d366a7ed1a7:
Assignee | ||
Comment 32•4 years ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #31)
Using the offsets from the crash report with the XUL object I was testing, here's the stack from https://crash-stats.mozilla.org/report/index/60038701-e0f0-4b8c-8ef2-2489a0200811 (from comment 27). Hope that helps.
XUL`create_from_CTFontRef: XUL`SkCreateTypefaceFromCTFont: XUL`mozilla::gfx::ScaledFontMac::CreateSkTypeface:
We need to figure out which line inside create_from_CTFontRef is actually recursing into CoreText, or rather, which specific CoreText function is the entry-point through which we go down the rabbit hole, otherwise this doesn't give us more information than what we already know...
Reporter | ||
Comment 33•4 years ago
|
||
I hit the crash in the debugger (while still running with Lee's latest patch applied.) Here's the full stack including the Apple library frames symbolicated showing we're calling GetSymbolicTraits() from create_from_CTFontRef().
(lldb) bt
* thread #26, name = 'WRWorker#3', stop reason = EXC_BAD_ACCESS (code=1, address=0x65e5e5e5e5f8)
* frame #0 libobjc.A.dylib`objc_msgSend()
frame #1 CoreGraphics`copy_name()
frame #2 CoreGraphics`add_root_name()
frame #3 CoreGraphics`CGFontNameTableCreate()
frame #4 CoreText`CopyFontNameInternal()
frame #5 CoreText`CopyFontName()
frame #6 CoreText`TBaseFont::CopyName()
frame #7 CoreText`TBaseFont::CreateTraitsValuesPerFontInfo()
frame #8 CoreText`TBaseFont::CopyTraitsInternal()
frame #9 CoreText`TBaseFont::CopyTraits()
frame #10 CoreText`TBaseFont::CreateTraitsValues()
frame #11 CoreText`TBaseFont::GetSymbolicTraitsInternal()
frame #12 CoreText`TBaseFont::GetSymbolicTraits()
frame #13 XUL`create_from_CTFontRef()
frame #14 XUL`SkCreateTypefaceFromCTFont()
frame #15 XUL`mozilla::gfx::ScaledFontMac::CreateSkTypeface()
frame #16 XUL`mozilla::gfx::ScaledFontBase::GetSkTypeface()
frame #17 XUL`mozilla::gfx::DrawTargetSkia::DrawGlyphs()
frame #18 XUL`mozilla::gfx::RecordedFillGlyphs::PlayEvent()
frame #19 XUL`std::__1::__function::__func<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0, std::__1::allocator<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::$_0>, bool (mozilla::gfx::RecordedEvent*)>::operator()()
frame #20 XUL`mozilla::gfx::RecordedEvent::DoWithEvent<mozilla::gfx::InlineTranslator::TranslateRecording(char*, unsigned long)::MemReader>()
frame #21 XUL`mozilla::gfx::InlineTranslator::TranslateRecording()
frame #22 XUL`wr_moz2d_render_cb()
frame #23 XUL`webrender_bindings::moz2d_renderer::rasterize_blob::h6787eeb41de8acba()
frame #24 XUL`core::ops::function::Fn::call::h1ef12582558278a4()
frame #25 XUL`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_mut::heb926afb0fefc8d7()
frame #26 XUL`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_once::hb335592a447ff9af()
frame #27 XUL`core::option::Option$LT$T$GT$::map::h5be409b13dcf33b9()
frame #28 XUL`_$LT$core..iter..adapters..Map$LT$I$C$F$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::h945d745a152b3aec()
frame #29 XUL`rayon::iter::plumbing::Folder::consume_iter::hc5934a669c47bb93()
frame #30 XUL`_$LT$rayon..iter..map..MapFolder$LT$C$C$F$GT$$u20$as$u20$rayon..iter..plumbing..Folder$LT$T$GT$$GT$::consume_iter::h2ce1de8952dcfc4c()
frame #31 XUL`rayon::iter::plumbing::Producer::fold_with::h59fc95442ccd8a5b()
frame #32 XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::h949aaa921f1e1a82()
frame #33 XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::_$u7b$$u7b$closure$u7d$$u7d$::ha03b62b142491f2b()
frame #34 XUL`rayon_core::join::join_context::call_a::_$u7b$$u7b$closure$u7d$$u7d$::h8e42927ce35c3541()
frame #35 XUL`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h76a138e7c8538bb4()
frame #36 XUL`std::panicking::try::do_call::hc3c7220546fbae1d()
frame #37 XUL`std::panicking::try::h6f286088405f7626()
frame #38 XUL`std::panic::catch_unwind::h2b371a79d4890314()
frame #39 XUL`rayon_core::unwind::halt_unwinding::hc0412d2a103e7a16()
frame #40 XUL`rayon_core::join::join_context::_$u7b$$u7b$closure$u7d$$u7d$::h50ecd8bdfe4d6c3b()
frame #41 XUL`rayon_core::registry::in_worker::h26d2af5ff8b00c3a()
frame #42 XUL`rayon_core::join::join_context::h24590f6b5d90b565()
frame #43 XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::h949aaa921f1e1a82()
frame #44 XUL`rayon::iter::plumbing::bridge_producer_consumer::helper::_$u7b$$u7b$closure$u7d$$u7d$::he007b6784453c0d4()
frame #45 XUL`rayon_core::join::join_context::call_b::_$u7b$$u7b$closure$u7d$$u7d$::h38243537e7de754a()
frame #46 XUL`_$LT$rayon_core..job..StackJob$LT$L$C$F$C$R$GT$$u20$as$u20$rayon_core..job..Job$GT$::execute::call::_$u7b$$u7b$closure$u7d$$u7d$::he27e2a11df578574()
frame #47 XUL`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h77ba6f60da98f281()
frame #48 XUL`std::panicking::try::do_call::h3264d28de8c82062()
frame #49 XUL`std::panicking::try::hab731d0c368455c2()
frame #50 XUL`std::panic::catch_unwind::hea260d291dbe1a91()
frame #51 XUL`rayon_core::unwind::halt_unwinding::he72aee99dee5e5b3()
frame #52 XUL`_$LT$rayon_core..job..StackJob$LT$L$C$F$C$R$GT$$u20$as$u20$rayon_core..job..Job$GT$::execute::ha9d805f3d1c122b0()
frame #53 XUL`rayon_core::registry::WorkerThread::execute::h820b7e3355ab3f5f()
frame #54 XUL`rayon_core::registry::WorkerThread::wait_until_cold::h2dcc51befd287871()
frame #55 XUL`rayon_core::registry::main_loop::h2a1e112526114ec9()
frame #56 XUL`rayon_core::registry::ThreadBuilder::run::h2059535dc8f33bf8()
frame #57 XUL`_$LT$rayon_core..registry..DefaultSpawn$u20$as$u20$rayon_core..registry..ThreadSpawn$GT$::spawn::_$u7b$$u7b$closure$u7d$$u7d$::h2e7a5fbfa4c36d67()
frame #58 XUL`std::sys_common::backtrace::__rust_begin_short_backtrace::h1a6757d7dd6c9a35()
frame #59 XUL`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::ha764aa9534ff383b()
frame #60 XUL`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h488aaae48e11255d()
frame #61 XUL`std::panicking::try::do_call::h225f2d491f35aa2b()
frame #62 XUL`std::panicking::try::h7b2bdc04410a1aef()
frame #63 XUL`std::panic::catch_unwind::hb51ae93c823680c0()
frame #64 XUL`std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::hea2ddf0431cc7023()
frame #65 XUL`std::sys::unix::thread::Thread::new::thread_start::hcced3d366a7ed1a7()
frame #66 libsystem_pthread.dylib`_pthread_start()
frame #67 libsystem_pthread.dylib`thread_start()
Comment 34•4 years ago
|
||
I see Lee has updated the patch to avoid the GetSymbolicTraits call as well (it looks like it's only used to set up the isFixedPitch flag, and AFAICS nothing we care about really depends on that). Let's hope that helps...
Assignee | ||
Comment 35•4 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #34)
I see Lee has updated the patch to avoid the GetSymbolicTraits call as well (it looks like it's only used to set up the isFixedPitch flag, and AFAICS nothing we care about really depends on that). Let's hope that helps...
Sadly there is a call to GetSymbolicTraits downwind merely a function away to figure out if it has color glyphs, so I would expect that this patch will only cause us to crash there now instead of when checking for fixed pitch. We may have to find the deeper root cause here, unless we can figure out or pass in the presence of color glyphs without having to query the CT font for it in a way that WR can get this knowledge too (not just thebes).
Comment 36•4 years ago
|
||
We could check for color glyphs by checking for the presence of the relevant font tables ('sbix'
, 'COLR'
, 'SVG '
) instead. On the thebes side, that'd be easily done via gfxFontEntry::HasFontTable
; not sure if there's a convenient helper on the WR side, but we could create one.
(I see that the rust code uses this to decide if it's a "bitmap" font -- I wonder if that will actually result in mishandling a font that has color glyphs but not bitmaps, i.e. 'COLR'
or 'SVG '
fonts? Originally, the only kind of color fonts on macOS were bitmaps, but that's not true these days.)
Updated•4 years ago
|
Comment 37•4 years ago
|
||
I have Bug Sir 11.0 Beta (20A5343i) with Firefox Dev Edition 80.0b8 installed and am encountering this issue like at least 30 times a day since a week or so (not exaggerating), to the point that I had to switch to another browser for the time being.
If I can somehow help with debugging, please do let me know - I will be more than happy to help.
Comment 38•4 years ago
|
||
I have the same version of macOS and Firefox and have the same issue as Oleg. I will be happy to help with thorough testing.
Assignee | ||
Comment 39•4 years ago
|
||
I put up new try builds with an updated version of my patch that should work around what I believe to be the remaining issues with the original workaround. Please get them and test them from here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=512e5ec6727755b9d88b4e19c37faeb65255221f
Assignee | ||
Updated•4 years ago
|
Comment 40•4 years ago
|
||
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ae4adc3f423c avoid letting Skia query style information for Mac fonts. r=jfkthame
Reporter | ||
Comment 41•4 years ago
|
||
I've been testing the patch today and have not encountered any problems.
Comment 42•4 years ago
|
||
(In reply to Haik Aftandilian [:haik] from comment #41)
I've been testing the patch today and have not encountered any problems.
Sorry for the noob question, but how to download a build?
Assignee | ||
Comment 43•4 years ago
|
||
(In reply to Vlad from comment #42)
(In reply to Haik Aftandilian [:haik] from comment #41)
I've been testing the patch today and have not encountered any problems.
Sorry for the noob question, but how to download a build?
Here's a direct link to the dmg in the try build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/B_vhW5DETGqirE6K5QqFNg/runs/0/artifacts/public/build/target.dmg
Comment 44•4 years ago
|
||
bugherder |
Comment 45•4 years ago
|
||
So far so good on the latest nightly build. We're aiming to respin the 80 release candidate today, it might be good to get this in?
Assignee | ||
Comment 46•4 years ago
|
||
Comment on attachment 9169067 [details]
Bug 1657440 - avoid letting Skia query style information for Mac fonts. r?jfkthame
Beta/Release Uplift Approval Request
- User impact if declined: High volume crash on macOS Big Sur beta.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
- String changes made/needed:
Assignee | ||
Updated•4 years ago
|
Comment 47•4 years ago
|
||
I ran the last test build hard yesterday and experienced none of this crash signature. Thanks for all the work on this, everyone!
Comment 48•4 years ago
|
||
Comment on attachment 9169067 [details]
Bug 1657440 - avoid letting Skia query style information for Mac fonts. r?jfkthame
Looking good on Nightly so far. Approved for 80.0rc2.
Comment 49•4 years ago
|
||
bugherder uplift |
Comment 50•4 years ago
|
||
Looking great on crash-stats for 80+.
Comment 51•4 years ago
|
||
I've updated macOS to Developer Beta 5 and Firefox 80.0b8 stopped crashing.
Reporter | ||
Comment 52•4 years ago
|
||
(In reply to Vlad from comment #51)
I've updated macOS to Developer Beta 5 and Firefox 80.0b8 stopped crashing.
I'm seeing the same. With Beta 5 (20A5354i) I have not hit any more of these crashes on Firefox Release 79. On crashstats, I see no reports for any of the signatures on Beta 5 indicating this may have been fixed in Beta 5.
Comment 53•4 years ago
|
||
Doesn't sound like we need to worry about backporting this to ESR78 then.
Updated•4 years ago
|
Description
•