1740889 - Investigate "RequestHelper::StartAndReturnResponse" content process shutdown hangs

Status: REOPENED

(Core :: Storage: localStorage & sessionStorage, task, P3)

Description

[Jens Stutte [:jstutte]]

We suspect the following to happen:

0. Local storage is yet not initialized in the parent process
1. A content process asks for some LS item
2. The parent process starts initialization on some background thread
3. The user does something and the parent process asks the content process to close
4. But the content process still waits on 1.

Comment 1

[Jens Stutte [:jstutte]]

For the records and as an opposite case to bug 1741131: Here we have a real SpinEventLoopUntil case, but the call is inlined:

 	ntdll.dll!NtWaitForAlertByThreadId()	Unbekannt
 	ntdll.dll!RtlSleepConditionVariableSRW()	Unbekannt
 	KERNELBASE.dll!SleepConditionVariableSRW()	Unbekannt
	mozglue.dll!mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl & lock) Zeile 50	C++
 	[Inlineframe] xul.dll!mozilla::OffTheBooksCondVar::Wait() Zeile 58	C++
 	xul.dll!mozilla::ThreadEventQueue::GetEvent(bool aMayWait, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> * aLastEventDelay) Zeile 171	C++
 	xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Zeile 1050	C++
 	xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Zeile 467	C++
> 	[Inlineframe] xul.dll!mozilla::SpinEventLoopUntil(const nsTSubstring<char> & aVeryGoodReasonToDoThis, mozilla::dom::`anonymous namespace'::RequestHelper::StartAndReturnResponse::<lambda_58> && aPredicate, nsIThread * aThread) Zeile 176	C++
 	[Inlineframe] xul.dll!mozilla::dom::`anonymous namespace'::RequestHelper::StartAndReturnResponse(mozilla::dom::LSRequestResponse & aResponse) Zeile 1222	C++
 	xul.dll!mozilla::dom::LSObject::DoRequestSynchronously(const mozilla::dom::LSRequestParams & aParams, mozilla::dom::LSRequestResponse & aResponse) Zeile 886	C++
 	xul.dll!mozilla::dom::LSObject::EnsureDatabase() Zeile 938	C++
 	xul.dll!mozilla::dom::LSObject::SetItem(const nsTSubstring<char16_t> & aKey, const nsTSubstring<char16_t> & aValue, nsIPrincipal & aSubjectPrincipal, mozilla::ErrorResult & aError) Zeile 684	C++
 	xul.dll!mozilla::dom::Storage_Binding::setItem(JSContext * cx, JS::Handle<JSObject *> obj, void * void_self, const JSJitMethodCallArgs & args) Zeile 233	C++
 	xul.dll!mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy,mozilla::dom::binding_detail::ThrowExceptions>(JSContext * cx, unsigned int argc, JS::Value * vp) Zeile 3300	C++

Comment 2

[Jens Stutte [:jstutte]]

This seems to still happen from time to time.

Comment 3

[Jens Stutte [:jstutte]]

Attachment: Bug 1740889 - Interrupt synchronous LS request if shutdown is expected. r?#dom-storage-reviewers

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8a78b2c43545
Interrupt synchronous LS request if shutdown is expected. r=dom-storage-reviewers,janv

Comment 5

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/8a78b2c43545

Comment 6

[Jens Stutte [:jstutte]]

This is still happening: https://crash-stats.mozilla.org/report/index/4603e917-5619-4ee8-af11-fb0280220908

Comment 7

[Jens Stutte [:jstutte]]

(In reply to Jens Stutte [:jstutte] from comment #6)

This is still happening: https://crash-stats.mozilla.org/report/index/4603e917-5619-4ee8-af11-fb0280220908

Here I see a running ClearRequestBase::DeleteFiles on the QuotaManager IO thread in the paired minidump of the parent process. I am wondering if this will make wait the LSRequestBase::RecvCancel that is supposed to delete our actor.

Comment 8

[Jan Varga [:janv]]

Jens, QuotaManager IO thread isn't currently used for any IPC communication. LSRequestBase::RecvCancel always run on the PBackground thread in the parent process. I checked the paired minidump and PBackground thread was inactive at that time (top frame is NtWaitForAlertByThreadId).

Comment 9

[Jens Stutte [:jstutte]]

(In reply to Jan Varga [:janv] from comment #8)

Jens, QuotaManager IO thread isn't currently used for any IPC communication. LSRequestBase::RecvCancel always run on the PBackground thread in the parent process. I checked the paired minidump and PBackground thread was inactive at that time (top frame is NtWaitForAlertByThreadId).

Yeah, that was what I had in mind, too - it was just the only strange thing happening in the parent process.