1718067 - Crash caused by MOZ_RELEASE_ASSERT(pid != kInvalidProcessId)

Status: RESOLVED FIXED

(Core :: IPC, defect, P3)

Description

[Sean Feng [:sefeng]]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/160b39f7-92d0-4def-9341-11c170210623

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(pid != kInvalidProcessId)

Top 7 frames of crashing thread:

0 XUL  dom/audiochannel/AudioChannelService.cpp:36
1 XUL mozilla::dom::ContentParent::ValidatePrincipal dom/ipc/ContentParent.cpp:1443
2 XUL mozilla::ipc::MessageChannel::Open ipc/glue/MessageChannel.cpp:806
3 XUL mozilla::gmp::PGMPVideoEncoderChild::SendParentShmemForPool ipc/ipdl/PGMPVideoEncoderChild.cpp:182
4 XUL mozilla::dom::AudioChannelService::AudioChannelWindow::AppendAudibleAgentIfNotContained dom/audiochannel/AudioChannelService.cpp:542
5 XUL mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2003
6 XUL mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:806

Comment 1

[Sean Feng [:sefeng]]

Actually, there are other crashes that have different signatures but the same crash reason. So this is probably not an audio issue.

Comment 2

[Andrew McCreight [:mccr8]]

This is caused by somebody calling OtherPid() on an Endpoint that hasn't been connected yet, so it may not be an IPC issue per se, but rather an error in how endpoints are handled.

AddAnimationToCompositorTable looks like a junk signature, FWIW. This stack doesn't make much sense: bp-2e5542be-98af-44b7-8ff0-b75ae0210624 and the other recent crash with this signature (which does not have the assert) looks even worse.

Comment 3

[Chris Peterson [:cpeterson]]

There are crash reports with reason MOZ_RELEASE_ASSERT(pid != kInvalidProcessId) from Firefox 78–91, but there is a recent spike in Nightly 91.

About 80% of the reports have Fission enabled, which is higher than the 60% of Nightly users with Fission enabled. So while this is not a Fission-specific crash, Fission might make more likely.

Comment 4

[Chris Peterson [:cpeterson]]

kmag confirms these crash reports looks bogus. They're not actionable, though the MOZ_RELEASE_ASSERT failure is surely real.

The crash volume is still very low, so let's just wait and see what happens.

Comment 5

[Chris Peterson [:cpeterson]]

Good news: Nika fixed this crash in IPC bug 1706374 in Nightly 91. Her fixed landed on 2021-06-23 and the last Nightly buildid that crashed as 20210622212907 from the day before.