1664713 - Crash in [@ mozilla::fontlist::FontList::ShareShmBlockToProcess]

Status: RESOLVED WORKSFORME

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

Description

[Gabriele Svelto [:gsvelto] (PTO)]

Crash report: https://crash-stats.mozilla.org/report/index/cb1a3c87-ff58-406b-9635-87a3c0200912

Top 10 frames of crashing thread:

0 xul.dll mozilla::fontlist::FontList::ShareShmBlockToProcess gfx/thebes/SharedFontList-impl.h:237
1 xul.dll gfxPlatformFontList::ShareFontListShmBlockToProcess gfx/thebes/gfxPlatformFontList.cpp:2459
2 xul.dll mozilla::dom::ContentParent::RecvGetFontListShmBlock dom/ipc/ContentParent.cpp:5273
3 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:15478
4 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2070
5 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953
6 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:512
7 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:86:7'>::Run xpcom/threads/nsThreadUtils.h:577
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
9 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:898

This crash first appeared in buildid 20200806215439. The raw crash reason is MOZ_CRASH(failed to share block). This only seems to be happening on nightly ATM.

Comment 1

[Jonathan Kew [:jfkthame]]

This is only enabled by default on Nightly currently, though presumably the same crash could happen for Beta or Release users if they have manually enabled the pref.

The MOZ_CRASH here indicates that a critical shared memory operation failed: we were unable to create a shmem handle to share to the content process that was requesting it. I'm not sure what circumstances could result in that; maybe resource exhaustion of some kind? The majority of the crashes appear to be from x86 (32-bit) Windows (7 or 10) with 4GB RAM or less, though I did see one Win10/x86_64/8GB system iirc.

Jed, can you throw any light on situations where ShareToProcess could be failing?

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

ShareToProcess on Windows is essentially mozilla::ipc::DuplicateHandle, a variation on the Windows API DuplicateHandle to accomodate being called from sandboxed processes; they can't safely have a handle to another process, so instead it takes a pid. In this case it's called from the parent process, so it should end up in the non-sandboxed case, which opens the target process to obtain a handle and then calls the real DuplicateHandle.

I don't see the IPCTransportFailureReason annotation in the crash metadata for the reports I looked at, which suggests that the parent process was able to open the content process, but failed to duplicate the handle. More than that I don't know; the documentation for DuplicateHandle doesn't give any hints about what errors it can produce.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

S2 seems appropriate more because it's a new bug than because of the volume of crashes, but this might not be actionable...

Comment 4

[Daniel Holbert [:dholbert]]

Retriaging as S3. Notes below:

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

S2 seems appropriate more because it's a new bug than because of the volume of crashes, but this might not be actionable...

Two years later, this is not a "new bug" anymore. :)

Also: I'm not sure what crash volume was like 2 years ago, but it looks like it's been moderate-to-low over the past 6 months, and it's especially low recently (the graph has been in the 0-2 range for the last 2 months or so).

Here are crashes for the past year:
https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Afontlist%3A%3AFontList%3A%3AShareShmBlockToProcess&date=%3E%3D2021-03-18T19%3A36%3A00.000Z&date=%3C2022-03-17T19%3A36%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-version&_sort=-date&page=1

In that list, right now it looks like the highest Firefox version that's gotten a crash report was 96.0a1, and that version only had 2 reports (on 2021-11-04 and 2021-11-09). All the other crashes are in 95 or earlier. (As of the time I'm writing this, Firefox official release version is currently at 98.0.1 and Nightly is at version 100.)

So: it's looking like this might have gone away after version 96?

One additional note: comment 1 mentioned this was about a Nightly-only feature ("shared font list"), which at the time would've explained low crash volume while still meriting some level of caution/worry. But nowadays the feature is enabled by default on all channels, as of bug 1694174 landing last year.

So: downgrading this to S3 as extremely-low-crash-volume, and we can perhaps close as WFM if we don't get any new reports in current versions of Firefox (as seems might be the case).

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.