1681759 - Crash in [@ mozilla::net::LoadInfo::SetController]

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, defect)

Description

[Sean Feng [:sefeng]]

Crash report: https://crash-stats.mozilla.org/report/index/48748394-1f0e-4207-9259-d7cda0201208

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(!isSome())

Top 10 frames of crashing thread:

0 xul.dll mozilla::net::LoadInfo::SetController netwerk/base/LoadInfo.cpp:1725
1 xul.dll mozilla::dom::ServiceWorkerInterceptController::ShouldPrepareForIntercept dom/serviceworkers/ServiceWorkerInterceptController.cpp:76
2 xul.dll mozilla::net::HttpBaseChannel::ShouldIntercept netwerk/protocol/http/HttpBaseChannel.cpp:3486
3 xul.dll mozilla::net::nsHttpChannel::Connect netwerk/protocol/http/nsHttpChannel.cpp:784
4 xul.dll mozilla::net::nsHttpChannel::ContinueOnBeforeConnect netwerk/protocol/http/nsHttpChannel.cpp:751
5 xul.dll mozilla::net::nsHttpChannel::OnBeforeConnect netwerk/protocol/http/nsHttpChannel.cpp:653
6 xul.dll mozilla::net::nsHttpChannel::HandleOnBeforeConnect netwerk/protocol/http/nsHttpChannel.cpp:546
7 xul.dll std::_Func_impl_no_alloc<`lambda at /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpChannel.cpp:499:21', nsresult, mozilla::net::nsHttpChannel*>::_Do_call 
8 xul.dll mozilla::net::nsHttpChannel::CallOrWaitForResume netwerk/protocol/http/nsHttpChannel.cpp:9353
9 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/netwerk/protocol/http/nsHttpChannel.cpp:6228:11'>::Run xpcom/threads/nsThreadUtils.h:534

Looks like there's an edge case that mController is not initialized, so the diagnostic assert fails.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Andrew, could you take a look?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

:valentin experienced this locally, identifying that this can be made to happen reliably with the evernote ServiceWorker, and what appears to be happening is that (with some hand-waving that I'll correct in a future comment):

• Precondition: There's a (?no-fetch?) ServiceWorker and the navigation ends up getting marked as controlled.
• The (network) request ends up getting redirected to a (same-origin) scope that matches a no-fetch ServiceWorker
• We end up trying to set the controller when a controller already exists, and the Maybe diagnostic-asserts because it rightly expects you won't do this (because it will cause a leak and violates invariants).

Comment 3

[Eden Chuang[:edenchuang]]

Attachment: Bug 1681759 - Clear the previous controller if the redirect mode is REDIRECT_MODE_FOLLOW before setting for a no-fetch handler controller.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e392a602a87
Clear the previous controller if the redirect mode is REDIRECT_MODE_FOLLOW before setting for a no-fetch handler controller. r=dom-worker-reviewers,asuth

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/3e392a602a87