Closed Bug 1708797 Opened 5 months ago Closed 5 months ago

Crash in [@ gfxDWriteFontList::PlatformGlobalFontFallback]

Categories

(Core :: Graphics: Text, defect)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox88 --- wontfix
firefox89 --- wontfix
firefox90 --- fixed

People

(Reporter: kashav, Assigned: jfkthame)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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.

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

Severity: -- → S3
Flags: needinfo?(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.

Flags: needinfo?(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.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/16316277d67e
Try to make font fallback code more robust against DWrite failures. r=lsalzman
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.