Investigate why the loading of browser.xhtml is cancelled
Categories
(Core :: Networking: JAR, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox89 | --- | fixed |
People
(Reporter: kershaw, Assigned: kershaw)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
There is one correlation of zero_byte_load and ysod events below. It seems one of the YSOD reasons is the loading of browser.xhtml was cancelled.
We'd like to know why and how this would happen.
zero_byte_load: [{"f":[{"v":"sync"},{"v":"false"}]},{"f":[{"v":"file_name"},{"v":"omni.ja!/chrome/browser/content/browser/browser.xhtml"}]},{"f":[{"v":"status"},{"v":"NS_BINDING_ABORTED"}]},{"f":[{"v":"cancelled"},{"v":"true"}]}]
ysod: [{"f":[{"v":"error_code"},{"v":"3"}]},{"f":[{"v":"location"},{"v":"1:1"}]},{"f":[{"v":"last_line"},{"v":""}]},{"f":[{"v":"last_line_len"},{"v":"0"}]}]
|
Assignee | |
Comment 1•3 years ago
•
|
||
I've added a assertion in nsJARChannel::Cancel to crash the browser when the loading of browser.xhtml is canceled by NS_BINDING_ABORTED.
It tuns out that one test on try will always hit the assertion I added.
According to the stacktrace below, it seems the cancellation is simply because a window is closed.
[task 2021-03-12T13:54:29.006Z] 13:54:29 INFO - GECKO(2187) | Assertion failure: !(mStatus == NS_BINDING_ABORTED && StringEndsWith(mSpec, "chrome/browser/content/browser/browser.xhtml"_ns)), at /builds/worker/checkouts/gecko/modules/libjar/nsJARChannel.cpp:568
[task 2021-03-12T13:54:29.009Z] 13:54:29 INFO - Initializing stack-fixing for the first stack frame, this may take a while...
[task 2021-03-12T13:54:34.991Z] 13:54:34 INFO - GECKO(2187) | #01: mozilla::net::DocumentLoadListener::Cancel(nsresult const&) [netwerk/ipc/DocumentLoadListener.cpp:976]
[task 2021-03-12T13:54:34.992Z] 13:54:34 INFO - GECKO(2187) | #02: mozilla::net::ParentProcessDocumentChannel::Cancel(nsresult) [netwerk/ipc/ParentProcessDocumentChannel.cpp:256]
[task 2021-03-12T13:54:34.995Z] 13:54:34 INFO - GECKO(2187) | #03: mozilla::net::nsLoadGroup::Cancel(nsresult) [netwerk/base/nsLoadGroup.cpp:231]
[task 2021-03-12T13:54:34.996Z] 13:54:34 INFO - GECKO(2187) | #04: nsDocLoader::Stop() [uriloader/base/nsDocLoader.cpp:253]
[task 2021-03-12T13:54:34.998Z] 13:54:34 INFO - GECKO(2187) | #05: nsDocShell::Stop(unsigned int) [docshell/base/nsDocShell.cpp:4392]
[task 2021-03-12T13:54:34.998Z] 13:54:34 INFO - GECKO(2187) | #06: nsDocShell::Destroy() [docshell/base/nsDocShell.cpp:4637]
[task 2021-03-12T13:54:34.999Z] 13:54:34 INFO - GECKO(2187) | #07: mozilla::AppWindow::Destroy() [xpfe/appshell/AppWindow.cpp:628]
[task 2021-03-12T13:54:34.999Z] 13:54:34 INFO - GECKO(2187) | #08: nsChromeTreeOwner::Destroy() [xpfe/appshell/nsChromeTreeOwner.cpp:255]
[task 2021-03-12T13:54:35.000Z] 13:54:34 INFO - GECKO(2187) | #09: nsGlobalWindowOuter::ReallyCloseWindow() [dom/base/nsGlobalWindowOuter.cpp:6278]
[task 2021-03-12T13:54:35.002Z] 13:54:35 INFO - GECKO(2187) | #10: nsCloseEvent::Run() [dom/base/nsGlobalWindowOuter.cpp:6082]
[task 2021-03-12T13:54:35.002Z] 13:54:35 INFO - GECKO(2187) | #11: mozilla::RunnableTask::Run() [xpcom/threads/TaskController.cpp:473]
[task 2021-03-12T13:54:35.002Z] 13:54:35 INFO - GECKO(2187) | #12: mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:760]
[task 2021-03-12T13:54:35.003Z] 13:54:35 INFO - GECKO(2187) | #13: mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) [xpcom/threads/TaskController.cpp:611]
[task 2021-03-12T13:54:35.003Z] 13:54:35 INFO - GECKO(2187) | #14: mozilla::TaskController::ProcessPendingMTTask(bool) [xpcom/threads/TaskController.cpp:395]
[task 2021-03-12T13:54:35.004Z] 13:54:35 INFO - GECKO(2187) | #15: mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() [xpcom/threads/nsThreadUtils.h:535]
[task 2021-03-12T13:54:35.004Z] 13:54:35 INFO - GECKO(2187) | #16: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1162]
[task 2021-03-12T13:54:35.004Z] 13:54:35 INFO - GECKO(2187) | #17: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:548]
I was wondering when the window is invisible or is closing, do we still report the YSOD event?
Zibi, do you probably have an idea here?
|
||
Comment 2•3 years ago
|
||
I was wondering when the window is invisible or is closing, do we still report the YSOD event?
Zibi, do you probably have an idea here?
I think we do. I'd assume that it would be very similar to the rapid-reload scenario where if the event trigger to close/reload document triggers network cancel mid-load, we'd still send YSOD.
Is there a way we could identify it in our probe and filter out zero_byte_loads that are result of reload or close trigger?
|
|
Assignee | |
Comment 3•3 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #2)
I was wondering when the window is invisible or is closing, do we still report the YSOD event?
Zibi, do you probably have an idea here?I think we do. I'd assume that it would be very similar to the rapid-reload scenario where if the event trigger to close/reload document triggers network cancel mid-load, we'd still send YSOD.
Is there a way we could identify it in our probe and filter out zero_byte_loads that are result of reload or close trigger?
Sorry for the late reply.
For the case that the window is closed, I think we should not sending ysod event when the document is hidden or the docshell is already destroyed.
For rapid-reload scenario, I can't find a easy way to filter this out. I think it's fine that we don't filter this out, since this scenario should happen rarely.
|
|
Assignee | |
Comment 4•3 years ago
|
||
Pushed by kjang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/13712c6df1a4 Extend ysod event telemetry to record the status of document r=zbraniecki
|
||
Comment 6•3 years ago
|
||
| bugherder | ||
Description
•