Closed Bug 1648353 Opened 2 years ago Closed 2 years ago

Crash in [@ gfxPlatformFontList::SetupFamilyCharMap]


(Core :: Graphics: Text, defect)

Windows 10



Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- unaffected
firefox79 --- disabled
firefox80 --- fixed


(Reporter: gsvelto, Assigned: jfkthame)




(Keywords: crash, regression)

Crash Data


(1 file)

This bug is for crash report bp-69146d9e-86a7-4d99-8945-9136d0200624.

Top 10 frames of crashing thread:

0 xul.dll gfxPlatformFontList::SetupFamilyCharMap gfx/thebes/gfxPlatformFontList.cpp:2419
1 xul.dll mozilla::dom::ContentParent::RecvSetupFamilyCharMap dom/ipc/ContentParent.cpp:5320
2 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:9629
3 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2092
4 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1971
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:501
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/
9 xul.dll MessageLoop::Run ipc/chromium/src/base/

This seems to have started with buildid 20200622214758. The raw crash reason is: MOZ_DIAGNOSTIC_ASSERT(false) (not a valid Family or AliasFamily pointer)

Severity: -- → S3
Flags: needinfo?(jfkthame)
Flags: needinfo?(jfkthame)
Regressed by: 1533462
Has Regression Range: --- → yes

OK, I think it was a mistake to make the failure conditions here issue MOZ_DIAGNOSTIC_ASSERT, which will crash the whole browser as this is running in the parent process. The failures here could indicate a damaged/compromised/buggy child process, but the crash report generated by the parent doesn't really provide any useful information as to what went wrong there.

In fact, there might not even be a bug at all; it might just indicate that the child sent a Family pointer that is out of range for the current list because the user has uninstalled/disabled some fonts, and the parent has reinitialized its list with fewer records, but the child hasn't yet handled that notification.

So we should remove the MOZ_DIAGNOSTIC_ASSERTs here, and just return safely in all error cases. I propose to leave a (debug-only) assertion in place for the misaligned pointer cases that would indicate an actual error rather than a transient issue during font-list-reinitialization; if we ever found a testcase that hits those it would be interesting to study. But crash reports from in-the-wild diagnostic asserts here provide no value.

Assignee: nobody → jfkthame
Pushed by
Remove/downgrade MOZ_DIAGNOSTIC_ASSERTs that may unnecessarily crash the parent process, but provide no useful data. r=jwatt
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
You need to log in before you can comment on or make changes to this bug.