Closed Bug 1718067 Opened 3 months ago Closed 2 months ago

Crash caused by MOZ_RELEASE_ASSERT(pid != kInvalidProcessId)

Categories

(Core :: IPC, defect, P3)

defect

Tracking

()

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

People

(Reporter: sefeng, Unassigned)

References

Details

(Keywords: crash)

Crash Data

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
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.

Status: NEW → RESOLVED
Closed: 2 months 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.