1708797 - Crash in [@ gfxDWriteFontList::PlatformGlobalFontFallback]

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[u608768]

Crash report: https://crash-stats.mozilla.org/report/index/1ee696b8-3997-4059-a282-805140210429

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 xul.dll gfxDWriteFontList::PlatformGlobalFontFallback gfx/thebes/gfxDWriteFontList.cpp:2151
1  @0x1675225a3cf 
2 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:766
3 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1159
4 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
5 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328
6 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:310
7 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
8 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:603
9 xul.dll nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:273

We saw a lot of these from a single installation in the 20210429122950 build. Might be a device-specific issue.

Comment 1

[Lee Salzman [:lsalzman]]

Jonathan, looks like maybe some sort of null-like pointer access happening there?

Comment 2

[Jonathan Kew [:jfkthame]]

Hard to tell exactly what's wrong; it seems to be within the IDWriteTextLayout::Draw call, so somewhere inside DWrite rather than in Firefox code.

I don't think the fallbackLayout itself can be NULL, as I'd expect that to result in a READ access of a pointer value slightly > 0, not a WRITE access at slightly < 0. And we error-check the result of the dwFactory->CreateTextLayout call.

I guess if the mFallbackRenderer is broken, that could be a cause; maybe the aFactory->GetSystemFontCollection call in the DWriteFontFallbackRenderer constructor failed? We have a (debug) assertion there, but in a release build we'd proceed with a null mSystemFonts, which sounds bad.

Or the breakage could be deeper inside DWrite, maybe related to a failure with a specific font that it tries to use; an i/o error accessing the font file might cause something like this.

Maybe we should just wrap the body of gfxDWriteFontList::PlatformGlobalFontFallback in an exception handler, so that any sort of internal DWrite failure in there doesn't crash the whole process. We can safely return NULL on any kind of exception, and let the rest of gecko deal with the failure to find a suitable font; that's not a fatal problem.

Comment 3

[Jonathan Kew [:jfkthame]]

Hmm, some of the crashes point to a different source location, and have EXCEPTION_PRIV_INSTRUCTION rather than the access violation:
e.g. https://crash-stats.mozilla.org/report/index/2dfb6171-79df-4efa-b849-8ff7c0210425. I don't see anything actionable about that; it looks more like a corrupted binary than anything else I can think of offhand.

For the exception within the DWrite call, though, we may still have a chance of handling it safely.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1708797 - Try to make font fallback code more robust against DWrite failures. r=lsalzman

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/16316277d67e
Try to make font fallback code more robust against DWrite failures. r=lsalzman

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/16316277d67e