1749744 - Crash in [@ (anonymous namespace)::ChildImpl::ThreadInfoWrapper::InitStarter]

Status: RESOLVED FIXED

(Core :: IPC, defect)

Description

[Calixte Denizet (:calixte)]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/42a315ff-10c2-4be6-bf1b-dfd560220112

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(!lock->mTaskQueue)

Top 10 frames of crashing thread:

0 xul.dll `anonymous namespace'::ChildImpl::ThreadInfoWrapper::InitStarter ipc/glue/BackgroundImpl.cpp:383
1 xul.dll static mozilla::ipc::BackgroundChild::InitSocketBridgeStarter ipc/glue/BackgroundImpl.cpp:749
2 xul.dll static mozilla::net::SocketProcessBridgeChild::Create netwerk/ipc/SocketProcessBridgeChild.cpp:36
3 xul.dll mozilla::net::SocketProcessBridgeChild::GetSocketProcessBridge::<lambda_40>::operator const netwerk/ipc/SocketProcessBridgeChild.cpp:113
4 xul.dll mozilla::MozPromise<mozilla::ipc::Endpoint<mozilla::net::PSocketProcessBridgeChild>, mozilla::ipc::ResponseRejectReason, 1>::ThenValue<`lambda at /builds/worker/checkouts/gecko/netwerk/ipc/SocketProcessBridgeChild.cpp:92:7'>::DoResolveOrRejectInternal xpcom/threads/MozPromise.h:914
5 xul.dll mozilla::MozPromise<mozilla::ProfileBufferChunkManagerUpdate, mozilla::ipc::ResponseRejectReason, 1>::ThenValueBase::ResolveOrRejectRunnable::Run xpcom/threads/MozPromise.h:487
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1217
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:885
8 xul.dll nsThreadPool::Shutdown xpcom/threads/nsThreadPool.cpp:408
9 xul.dll mozilla::detail::RunnableMethodImpl<D3DVsyncSource::D3DVsyncDisplay*, void  xpcom/threads/nsThreadUtils.h:1200

There is 1 crash in nightly 98 with buildid 20220111213255. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1737828.

[1] https://hg.mozilla.org/mozilla-central/rev?node=43cd1d6eb145

Comment 1

[Dragana Damjanovic [:dragana]]

Kershaw, can you also take a look?

Comment 2

[Nika Layzell [:nika] (ni? for response)]

It appears as though this is caused by the socket process dying, and therefore needing to re-start the socket process bridge to be able to perform network connections over it. Unfortunately it doesn't seem like we have any tests for that case in-tree so I wasn't able to catch it early.

According to :dragana on matrix, we currently don't support restarting the socket process, which explains why this doesn't have a test. I have a fix locally which updates the BackgroundStarterChild implementation to support restarting the socket process, but I won't be able to test it fully.

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1749744 - Handle re-creating PBackgroundStarter, r=handyman,kershaw

This is possible if the socket process bridge ends up being restarted,
so needs to be handled as an edge-case. The approach taken here is to
tightly couple the task queue, pid, and BackgroundStarterChild instances
so that they can be swapped out at runtime whenever InitStarter is
called.

There is no test in the current patch as it is apparently still
unsupported to restart the socket process after a crash.

Comment 4

[Kershaw Chang [:kershaw]]

Thanks for taking this, Nika.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0345b0ad2536
Handle re-creating PBackgroundStarter, r=handyman,kershaw

Comment 6

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/0345b0ad2536