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

Status: RESOLVED WORKSFORME

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

Description

[Gabriele Svelto [:gsvelto]]

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.

Comment 1

[Gabriele Svelto [:gsvelto]]

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

Comment 2

[Andrew McCreight [:mccr8]]

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

Comment 3

[Chris Peterson [:cpeterson]]

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

Comment 4

[Rachel Tublitz [:rachel]]

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

Comment 5

[Chris Peterson [:cpeterson]]

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

Comment 6

[Wayne Mery (:wsmwk)]

Firefox has a 2x crash rate increase during September. Looks like 91.0.2 ?
https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Adom%3A%3AContentParent%3A%3AActorDestroy&date=%3E%3D2021-06-19T03%3A20%3A00.000Z&date=%3C2021-09-19T03%3A20%3A00.000Z#graphs

Comment 7

[Jens Stutte [:jstutte]]

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

Comment 8

[Wayne Mery (:wsmwk)]

mozilla::dom::ContentParent::ActorDestroy dies out after Firefox 100.0b3

For Thunderbird, the crash doesn't exist in version 102.

Comment 9

[Jens Stutte [:jstutte]]

The diagnostic crash is for sure gone. The remaining two crashes in release in the same function seem to be unrelated, one looks like a problem accessing the page file, the other looks quite bogus, too.