Open Bug 1638795 Opened 2 years ago Updated 1 year ago

MOZ_DIAGNOSTIC_ASSERT Crash in [@ mozilla::dom::ContentParent::ActorDestroy]

Categories

(Core :: DOM: Content Processes, defect, P3)

Unspecified
All
defect

Tracking

()

Tracking Status
firefox78 --- affected

People

(Reporter: gsvelto, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-2731805e-0efe-4c16-8d3c-419d90200516.

Top 10 frames of crashing thread:

0 XUL mozilla::dom::ContentParent::ActorDestroy dom/ipc/ContentParent.cpp:1729
1 XUL mozilla::ipc::IProtocol::DestroySubtree ipc/glue/ProtocolUtils.cpp:566
2 XUL mozilla::dom::PContentParent::OnChannelClose ipc/ipdl/PContentParent.cpp:14746
3 XUL mozilla::dom::ContentParent::ShutDownProcess dom/ipc/ContentParent.cpp:1480
4 XUL mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:9683
5 XUL mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2186
6 XUL mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1989
7 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1211
8 XUL NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:501
9 XUL mozilla::layers::CompositorThreadHolder::Shutdown gfx/layers/ipc/CompositorThread.cpp:132

We're crashing due to this assertion: MOZ_ALWAYS_TRUE(mContentParentMap.Remove(aChildCpId)). The first affected buildid appears to be 20200504222419.

Note that the crashes not happening on nightly are unrelated and useless, ignore them.

Looking for other crashes with this same assertion, I found another signature.

Crash Signature: [@ mozilla::dom::ContentParent::ActorDestroy] → [@ mozilla::dom::ContentParent::ActorDestroy] [@ mozilla::dom::ContentProcessManager::RemoveContentProcess ]

MOZ_ALWAYS_TRUE is now a MOZ_DIAGNOSTIC_ASSERT instead of a debug MOZ_ASSERT. This diagnostic crash will only affect Nightly and DevEdition.

This is a race when content process crashes early during startup so mContentParentMap doesn't know about aChildCpId yet. If an error occurs after Open, but before the call to AddContentProcess which causes the channel to close, this assertion fires:

https://searchfox.org/mozilla-central/rev/df4c90d4b8c92c99f76334acfe4813c573c12661/dom/ipc/ContentParent.cpp#2115-2130

Severity: -- → S2
Priority: -- → P3

S1 or S2 bugs needs an assignee - could you find someone for this bug?

Flags: needinfo?(nkochar)

(In reply to Rachel Tublitz [:rachel] from comment #4)

S1 or S2 bugs needs an assignee - could you find someone for this bug?

I'm downgrading the severity to S3. While there are some old crash reports with this same signature, this new crash is a diagnostic assertion failure that is only enabled in the Nightly and DevEdition channels. Plus the crash volume in Nightly is pretty low.

Severity: S2 → S3
Flags: needinfo?(nkochar)
Summary: Crash in [@ mozilla::dom::ContentParent::ActorDestroy] → MOZ_DIAGNOSTIC_ASSERT Crash in [@ mozilla::dom::ContentParent::ActorDestroy]
Blocks: 1719869

Apparently all remaining crashes here, also from Nightly and early Beta, are the same nullptr access as in bug 1719869.

Flags: needinfo?(jstutte)
You need to log in before you can comment on or make changes to this bug.