Crash in [@ shutdownhang | nsThread::Shutdown | mozilla::LazyIdleThread::ShutdownThread]
Categories
(External Software Affecting Firefox :: Telemetry, defect, P1)
Tracking
(firefox71 fixed)
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: bugzilla, Assigned: bugzilla)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
This bug is for crash report bp-1dc8f833-02fc-459c-b147-10b520190926.
Top 10 frames of crashing thread:
0 ntdll.dll NtWaitForAlertByThreadId
1 ntdll.dll RtlSleepConditionVariableSRW
2 kernelbase.dll SleepConditionVariableSRW
3 mozglue.dll mozilla::detail::ConditionVariableImpl::wait mozglue/misc/ConditionVariable_windows.cpp:50
4 xul.dll struct already_AddRefed<nsIRunnable> mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue>::GetEvent xpcom/threads/ThreadEventQueue.cpp:153
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1134
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:900
8 xul.dll mozilla::LazyIdleThread::ShutdownThread xpcom/threads/LazyIdleThread.cpp:276
9 xul.dll mozilla::LazyIdleThread::Shutdown xpcom/threads/LazyIdleThread.cpp:465
This is because the background thread is running at low priority. The main thread is blocked on it during shutdown (but not truly blocked from a kernel perspective, as the main thread continues to spin its event loop; the kernel doesn't "see" the dependency between the main thread and the background thread, so priority inheritance can't kick in).
The current method that we're using for dropping priority is by calling SetThreadPriority
with THREAD_MODE_BACKGROUND_BEGIN
. Unfortunately that technique also requires that THREAD_MODE_BACKGROUND_END
be called on its own thread; a different thread cannot raise the background thread out of that mode using that flag.
We should investigate how the older constants such as THREAD_PRIORITY_NORMAL
affect a thread in background mode. If they have no effect then untrusted modules may need to THREAD_PRIORITY_IDLE
/ THREAD_PRIORITY_NORMAL
instead so that the main thread can bump the background thread's priority during shutdown.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
To ensure that we do not block shutdown while waiting on a low-priority
untrusted modules thread:
-
We switch to using
THREAD_PRIORITY_IDLE
andTHREAD_PRIORITY_NORMAL
instead ofTHREAD_MODE_BACKGROUND_BEGIN
andTHREAD_MODE_BACKGROUND_END
.
This is necessary because the latter flags only work when settting priority
on the current thread; they do not permit other threads to alter them. -
We add
BackgroundPriorityRegion::Clear
to normalize the specified thread's
priority. -
We invoke
BackgroundPriorityRegion::Clear
on the untrusted modules thread
as soon as we learn that we will be shutting down, thus boosting the thread's
priority to normal.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Comment 5•5 years ago
|
||
bugherder |
Comment 6•5 years ago
|
||
== Change summary for alert #23300 (as of Tue, 01 Oct 2019 10:43:07 GMT) ==
Improvements:
24% tp5n main_startup_fileio windows10-64-shippable-qr opt e10s stylo 773,351.00 -> 585,020.33
9% tp5n nonmain_normal_fileio windows10-64-shippable-qr opt e10s stylo 521,751,962.62 -> 473,831,840.92
9% tp5n nonmain_normal_fileio windows10-64-shippable-qr opt e10s stylo 527,583,744.00 -> 481,135,167.92
7% tp5n nonmain_normal_fileio windows7-32-shippable opt e10s stylo 425,244,152.42 -> 394,528,221.83
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=23300
Updated•3 years ago
|
Description
•