1678972 - Crash in [@ gfxDWriteFontList::CreateFontEntry]

Status: RESOLVED DUPLICATE of bug 1681918

(Core :: Layout: Text and Fonts, defect, P2)

Description

[blinky]

I can reproduce the crash on Windows 7 VM.

Steps to reproduce:

1. Open attachment 9097246 [details] in first tab.
2. Open attachment 9159611 [details] in four tabs.
3. Download and install the font Pinyin1712.ttf.
4. Uninstall the font Pinyin1712.ttf.

See https://youtu.be/vHYv4AbfG4M

Actual results:

The tab crashed.

Crash report: bp-1174e152-8103-49a1-bdbb-623b90201123

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll gfxDWriteFontList::CreateFontEntry gfx/thebes/gfxDWriteFontList.cpp:999
1 xul.dll gfxPlatformFontList::InitFontList gfx/thebes/gfxPlatformFontList.cpp:534
2 xul.dll gfxPlatformFontList::UpdateFontList gfx/thebes/gfxPlatformFontList.cpp:803
3 xul.dll gfxPlatform::UpdateFontList gfx/thebes/gfxPlatform.cpp:1807
4 xul.dll mozilla::dom::ContentChild::RecvRebuildFontList dom/ipc/ContentChild.cpp:2409
5 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:10516
6 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2070
7 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:720
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1194
9 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109

Comment 1

[blinky]

The full dump is here https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211523&authkey=AJjMIKGSWpyRrSw.

Comment 2

[blinky]

This also happens on Windows 10, crash report from a user bp-9800aefa-e06b-4516-a931-5fd500201119.

Comment 3

[Jonathan Kew [:jfkthame]]

I've seen this sporadically on some try runs recently, too. It appears that when we re-initialize the font list (due to a change in system font configuration, such as installing or uninstalling a font file as in the STR here), our call to GetSystemFontCollection may sometimes fail in one or more of the content processes, although it worked in the parent process and so we have a "valid" shared font list on hand.

The crash report in comment 2 shows a similar failure happening in a content process at startup; here, the parent must have successfully initialized DWrite, but then the call in the child fails and we end up with a null mSystemFonts.

I've just posted a patch in bug 1681918 that might mitigate some of this, by making the child process abandon the shared font list if it fails to get the system font collection; however, I think it's likely that we're still going to hit some kind of crash pretty soon if DirectWrite is failing under us. Not sure how many such failures we can realistically catch and recover from. :-(

Comment 4

[Jonathan Kew [:jfkthame]]

Hi blinky -- I wonder, can you still reproduce this with current Nightly? I just tried and couldn't get it to crash on my win10 machine. I am hoping that along with bug 1681918, one of the changes made by the patch in bug 1676966 might have helped here.

(Though win7 might still be a problem, if DirectWrite calls start failing.)

Comment 5

[blinky]

I can not reproduce the crash after bug 1681918 is fixed. Thanks.

Comment 6

[Jonathan Kew [:jfkthame]]

That's great, thanks! Let's dupe this forward to bug 1681918, then.