Open Bug 1740889 Opened 11 months ago Updated 14 days ago

Investigate "RequestHelper::StartAndReturnResponse" content process shutdown hangs

Categories

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

task

Tracking

()

REOPENED
106 Branch
Tracking Status
firefox106 --- affected

People

(Reporter: jstutte, Assigned: jstutte)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

We suspect the following to happen:

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

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++

Severity: -- → S3
Priority: -- → P3
Assignee: nobody → jstutte
Status: NEW → ASSIGNED
Pushed by jstutte@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8a78b2c43545
Interrupt synchronous LS request if shutdown is expected. r=dom-storage-reviewers,janv
Status: ASSIGNED → RESOLVED
Closed: 24 days ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch
Blocks: 1789231
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

Flags: needinfo?(jvarga)

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

Flags: needinfo?(jvarga)

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

You need to log in before you can comment on or make changes to this bug.