Closed Bug 1718067 Opened 1 year ago Closed 1 year ago

Crash caused by MOZ_RELEASE_ASSERT(pid != kInvalidProcessId)


(Core :: IPC, defect, P3)




Fission Milestone MVP
Tracking Status
firefox-esr78 --- wontfix
firefox89 --- wontfix
firefox90 --- wontfix
firefox91 --- fixed


(Reporter: sefeng, Unassigned)



(Keywords: crash)

Crash Data

Maybe Fission related. (DOMFissionEnabled=1)

Crash report:

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
Severity: -- → S2

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

Crash Signature: [@ (anonymous namespace)::AudioPlaybackRunnable::~AudioPlaybackRunnable] → [@ (anonymous namespace)::AudioPlaybackRunnable::~AudioPlaybackRunnable] [@ mozilla::dom::ContentParent::HandleOrphanedMinidump ] [@ mozilla::SMILAnimationController::AddAnimationToCompositorTable ]
Component: Audio/Video → IPC
Summary: Crash in [@ (anonymous namespace)::AudioPlaybackRunnable::~AudioPlaybackRunnable] → Crash caused by MOZ_RELEASE_ASSERT(pid != kInvalidProcessId)

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.

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.

Fission Milestone: --- → ?
OS: Unspecified → All
Hardware: Unspecified → All

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.

Fission Milestone: ? → ---
Priority: -- → P3
Fission Milestone: --- → MVP

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.

Closed: 1 year ago
Depends on: 1706374
Resolution: --- → FIXED
See Also: → 1725114
You need to log in before you can comment on or make changes to this bug.