1673716 - Crash in [@ AsyncShutdownTimeout | quit-application-granted | AboutHom...
source link: https://bugzilla.mozilla.org/show_bug.cgi?id=1673716
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Crash in [@ AsyncShutdownTimeout | quit-application-granted | AboutHomeStartupCache: Writing cache]
Categories
(Firefox :: New Tab Page, defect, P3)
Tracking
(bug RESOLVED as FIXED)
85 Branch
People
(Reporter: aryx, Assigned: mconley)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
1 installation (OS X 10.12)
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/d27f47b6-89d8-4cc8-b39c-5dcf60201027
MOZ_CRASH Reason: MOZ_CRASH()
Top 10 frames of crashing thread:
0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 XUL NS_DebugBreak xpcom/base/nsDebugImpl.cpp:435
2 XUL nsDebugImpl::Abort xpcom/base/nsDebugImpl.cpp:134
3 XUL NS_InvokeByIndex
4 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1142
5 XUL XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:925
6 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:598
7 XUL Interpret js/src/vm/Interpreter.cpp:3336
8 XUL js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:635
9 XUL js::Call js/src/vm/Interpreter.cpp:680
Looking at that crash report, we're timing out in an AsyncShutdown blocker with this metadata:
{"phase":"quit-application-granted","conditions":[{"name":"AboutHomeStartupCache: Writing cache","state":"Getting cache streams","filename":"resource:///modules/BrowserGlue.jsm","lineNumber":5194,"stack":["resource:///modules/BrowserGlue.jsm:init:5194","resource:///modules/BrowserGlue.jsm:BG__beforeUIStartup:1419","resource:///modules/BrowserGlue.jsm:BG_observe:1041"]}]}
So the AboutHomeStartupCache is timing out waiting for the privileged about content process to return the cache streams here:
I wonder if this can occur if the privileged about content process is force-killed before it has a chance to respond. We should probably update the AboutHomeStartupCache to notice if there's a _cacheDeferred
available on AboutHomeStartupCache when the privileged about content process causes ipc:content-shutdown
to fire, and if so, make sure we resolve it.
Pushed by [email protected]: https://hg.mozilla.org/mozilla-central/rev/b38c39fa6915 Resolve the about:home startup cache request if the privileged about content process crashes. r=Gijs
Yeah, this didn't fix it. :/ It's strictly an improvement, I believe, but didn't fix the overall issue.
Pushed by [email protected]: https://hg.mozilla.org/integration/autoland/rev/5fdcb0dfa86f Try to make sure the about:home startup cache worker construction Promise always resolves. r=Gijs
The severity field is not set for this bug.
:thecount, could you have a look please?
For more information, please visit auto_nag documentation.
This is currently not enabled by default outside of Firefox Nightly, so setting Severity to N/A.
It is theoretically possible for two about:home documents to be loading
at the same time during startup (for example, if the user passed in a series
of URLs to open via the command-line, including multiple about:home's).
This patch ensures that only one of those documents (the first to load)
gets to consume the cached streams.
The severity field is not set for this bug.
:thecount, could you have a look please?
For more information, please visit auto_nag documentation.
Pushed by [email protected]: https://hg.mozilla.org/integration/autoland/rev/dc9ac32cc19b Ensure the about:home startup cache can only be used by one BrowsingContext. r=Gijs https://hg.mozilla.org/integration/autoland/rev/113f5e76a871 Make AboutHomeStartupCache ignore all but the first privileged about content process. r=Gijs
The crash volume is unchanged since the patches landed. Shall this bug be reopened?
Pushed by [email protected]: https://hg.mozilla.org/integration/autoland/rev/7a360fe377ea Only wait for 1 second when trying to create about:home startup cache on shutdown. r=emalysz
Too early to say whether or not we've brought down the frequency of the AsyncShutdown crashes, but it's clear we haven't eliminated them. Reopening. sigh.
It looks like the previous patch landings have had no effect whatsoever.
Upon examination, it appears that DeferredTask will wait for a previous instance of the task to fire on finalization if one was already underway... so I suppose it's possible that one of the previous cache tasks has just died on us, which is why we're timing out here. In that case, we wouldn't enter the finalized branch of cacheNow
that the last patch added. I think maybe I should move the timeout within the onShutdown
method instead.
In an earlier attempt to fix this shutdown hang, a timeout was added to the cacheNow
task function to try to have a maximum of 1s of wait time during the shutdown blocker
before giving up and letting the shutdown proceed.
This didn't seem to put a dent in the shutdown hangs. It looks like DeferredTasks
that are being finalized don't actually re-enter the task if the task was already
running, which might explain why in some cases the timeout wasn't being hit. This
patch makes sure that the timeout is being used regardless of whether or not the
cache task is already underway.
Pushed by [email protected]: https://hg.mozilla.org/integration/autoland/rev/fc5b2058d79a Move the AboutHomeStartupCache shutdown blocker timeout to the onShutdown method. r=emalysz
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK