1657440 - [macOS 11 Beta] CoreText crash in call out of Skia fontstyle_from_descriptor()

Status: VERIFIED FIXED

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

Description

[Haik Aftandilian [:haik]]

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.

Comment 3

[phinze]

👋 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

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This is a very frequent crash with the latest macOS Big Sur beta (beta 4). Lee, can you take a look at this?

Comment 5

[Lee Salzman [:lsalzman]]

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

[Jonathan Kew [:jfkthame]]

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

[Dzmitry Malyshau [:kvark]]

Markus, did you manage to install Big Sur? This issue is in dire need of somebody looking at it.
Marking as S2 for now.

Comment 9

[Lee Salzman [:lsalzman]]

Attachment: Bug 1657440 - generate SkFontStyle for Mac fonts from gfxFontStyle. r?jfkthame

Comment 10

[Lee Salzman [:lsalzman]]

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

[Markus Stange [:mstange]]

Unfortunately I still don't have a Big Sur install. It's something I'll need to tackle soon.

Comment 12

[eric]

I can try this out once the build is ready.

Comment 13

[eric]

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

[eric]

"OS X Cross Compiled shippable opt" is also working which convinces me the patch is sufficient.

Comment 15

[phinze]

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

[phinze]

Heh, and minutes after posting that I get a hard / full-browser crash. Might be unrelated? Here's the dump.

Comment 17

[Jonathan Kew [:jfkthame]]

Yeah, that looks like an unrelated issue.

Comment 18

[phinze]

Here's another hard crash.

The Thread 18 Crashed:: WRWorker#0 stack looks like it might be in the vicinity?

Comment 19

[Lee Salzman [:lsalzman]]

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

[Jonathan Kew [:jfkthame]]

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?

Comment 22

[Haik Aftandilian [:haik]]

I have reached out to our Apple contact to see if this is a known issue with the Beta.

Comment 23

[Lee Salzman [:lsalzman]]

Attachment: Bug 1657440 - avoid letting Skia query style information for Mac fonts. r?jfkthame

Comment 24

[Lee Salzman [:lsalzman]]

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

[phinze]

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

Comment 26

[Haik Aftandilian [:haik]]

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.

Comment 27

[Haik Aftandilian [:haik]]

(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

Comment 28

[Lee Salzman [:lsalzman]]

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

[Jonathan Kew [:jfkthame]]

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

Comment 30

[Haik Aftandilian [:haik]]

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

Comment 31

[Haik Aftandilian [:haik]]

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:

Comment 32

[Lee Salzman [:lsalzman]]

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

Comment 33

[Haik Aftandilian [:haik]]

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

[Jonathan Kew [:jfkthame]]

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

Comment 35

[Lee Salzman [:lsalzman]]

(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

[Jonathan Kew [:jfkthame]]

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

Comment 37

[oleg]

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

[Vlad]

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.

Comment 39

[Lee Salzman [:lsalzman]]

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

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ae4adc3f423c
avoid letting Skia query style information for Mac fonts. r=jfkthame

Comment 41

[Haik Aftandilian [:haik]]

I've been testing the patch today and have not encountered any problems.

Comment 42

[Vlad]

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

Comment 43

[Lee Salzman [:lsalzman]]

(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

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/ae4adc3f423c

Comment 45

[Julien Cristau [:jcristau] (back April 22)]

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?

Comment 46

[Lee Salzman [:lsalzman]]

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:

Comment 47

[phinze]

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

[Ryan VanderMeulen [:RyanVM]]

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

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/1217fa56d549

Comment 50

[Ryan VanderMeulen [:RyanVM]]

Looking great on crash-stats for 80+.

Comment 51

[Vlad]

I've updated macOS to Developer Beta 5 and Firefox 80.0b8 stopped crashing.

Comment 52

[Haik Aftandilian [:haik]]

(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

[Ryan VanderMeulen [:RyanVM]]

Doesn't sound like we need to worry about backporting this to ESR78 then.