SessionStoreListener code tries to read layout and form data for windows loaded in a different child process
Categories
(Firefox :: Session Restore, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: alchen, Assigned: farre)
References
(Blocks 1 open bug, Regressed 4 open bugs)
Details
Attachments
(3 files, 9 obsolete files)
Originally, we use "docShell->GetChildCount()" and "docShell->GetChildAt()" to iterate all childs. Now we use "browsingContext->GetChildren()" to achieve it.
However, it is not going to work for fission (the window for the children might live in a different process)
Here are the current consumers.
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/toolkit/components/sessionstore/SessionStoreListener.cpp#405
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/toolkit/components/sessionstore/SessionStoreListener.cpp#493
https://searchfox.org/mozilla-central/rev/e0b0c38ee83f99d3cf868bad525ace4a395039f1/toolkit/components/sessionstore/SessionStoreUtils.cpp#1294
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
So, I think that this does work. BrowsingContext::GetChildren().Length() should reflect all browsing context children of a parent, since they're synced on creation (and removal). Or am I missing something?
Updated•5 years ago
|
Reporter | ||
Comment 2•5 years ago
|
||
This bug is from Peter's review.
(In reply to Andreas Farre [:farre] from comment #1)
So, I think that this does work. BrowsingContext::GetChildren().Length() should reflect all browsing context children of a parent, since they're synced on creation (and removal). Or am I missing something?
Peter, any comment?
Comment 3•5 years ago
|
||
The problem is not the GetChildren call, the problem is that we then for each of the child browsing contexts do GetDOMWindow. We null-check the result of GetDOMWindow and return early, but we should really be collecting the data for each of the children. This probably requires messaging the process that the child BC is loaded in to collect the data, and merge all that data somewhere.
Updated•5 years ago
|
Reporter | ||
Comment 4•5 years ago
|
||
When enabling fission, "browser/components/sessionstore/test/browser_sessionStorage.js" is failed due to this bug.
Comment 5•4 years ago
|
||
M6c because we don't want to lose form data.
Updated•4 years ago
|
We currently sequentially walk the BrowsingContext subtree and collect data from each Document that we come across. This doesn't work with fission because it's possible that a context in the tree is out-of-process.
As far as I can tell, there's 2 possible solutions: query each content process in the subtree for the information that we need (and then collect everything and return that array), or store this data on WindowContext. We're dealing with form data, which probably shouldn't be synced to all processes, so the latter probably isn't correct.
So this will probably looking something like:
- the initial root context sends a message to its
ContentParent
requesting the form/scroll data - from there, we query each
ContentChild
in the root's subtree for the fields we need - those queries resolve and the root
ContentParent
has an array of data that we now need to get back to the content process that this started in
I'm unsure how that 3rd step should work, or if this is even the correct approach. Does that initial message need to be sync? nika, do you have any ideas here?
Updated•4 years ago
|
Comment 7•4 years ago
|
||
(In reply to :kashav from comment #6)
As far as I can tell, there's 2 possible solutions: query each content process in the subtree for the information that we need (and then collect everything and return that array), or store this data on WindowContext. We're dealing with form data, which probably shouldn't be synced to all processes, so the latter probably isn't correct.
Yeah, we shouldn't be storing this information in WindowContext, so we'll want to have a query which is sent to all relevant processes, to collect the information.
So this will probably looking something like:
- the initial root context sends a message to its
ContentParent
requesting the form/scroll data
Ideally, we wouldn't start this data collection process from the content process, but instead from the parent process. Currently we generally trigger updates from the content process, but it should be possible to switch this around and instead trigger updates from the parent process instead.
The following are the cases where we are synchronously triggering an update:
- When the tab is first created: https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#190
- This is also possible to perform from the parent process, so shouldn't be a big deal.
- When the parent process is requesting a flush: https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#662 and https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/dom/ipc/BrowserChild.cpp#1914
- This is inherently triggered by the parent process.
- If the
browser.sessionstore.debug.no_auto_updates
pref is enabled:https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#253- This is test-only, so it should be possible to work around whatever particular requirements it has for the specific tests.
- I think doing what I'm going to suggest below, but just not setting the timer in the parent process, might be good enough for the tests.
- When an immediate SHistory update is requested: https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#668
- This should be triggered by the parent process, so shouldn't be an issue.
All of the other cases are triggered off of a timer set in AddTimerForUpdate
(https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#257-259). It should be possible to change this logic to instead send a message to the parent process, get it to set the timer, and then trigger data collection in every relevant content process once the timer expires. This could look something like the following:
- Each BrowserChild has a bool,
mHasRequestedSessionStoreUpdate
. (bikeshed away) - When an update is requested, set to true, and if it was previously false, send a message to the parent process.
- Each root BrowserParent has a bool,
mIsFlushingSessionStore
, which istrue
while an ongoing sessionstore flush is happening. If the request arrives while this is true, the request is ignored - Each root BrowserParent also has a timer which is set when a new request arrives.
- When the timer expires, the parent process will perform a sessionstore flush by sending a "please flush" message to every relevant content process through
Group()->EachParent()
, passing the BrowsingContext root which needs to be flushed. - Each process, in response to this message, will:
- Collect the relevant information
- Resolve the request with the information that process has available (probably as pairs, like
(BCID, InformationCollected)
). - Clear any
mHasRequestedSessionStoreUpdate
flags in the flushed tree back to false.
- The parent process will then have to stich the information back together after all queries are resolved, by taking the BrowsingContext tree, looking up the information across all content processes, and building the final data.
- The parent process might want to start with the current state, and stitch in new information as it's received from each content process, so that we never lose information even if one process never responds? This is probably follow-up work.
In some of the triggers cases, it may even be possible to avoid listening in the content process at all. For example DOMTitleChanged
would be possible to listen for from the parent process (https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#361-363), as would all of the observer notifications, which are for pref changes and sessionStorage being purged (https://searchfox.org/mozilla-central/rev/23dd7c485a6525bb3a974abeaafaf34bfb43d76b/toolkit/components/sessionstore/SessionStoreListener.cpp#404-436), and Session History, once that is moved to the parent.
Updated•4 years ago
|
Updated•4 years ago
|
This changes both how we collect session store data and how we trigger tab state
flushes. These changes are summarized below. Comment #7 of bug 1572084 has some
extra details.
- A single session store flush may span multiple content processes, so the data
collection process can no longer be triggered from a content process.
Instead of maintaining its own flush timer, TabListener now sends a message
to its corresponding BrowserParent requesting a timer be created. This
BrowserParent hosts the toplevel BrowsingContext for the tree that is being
flushed. - When that timer expires, the parent process queries each content processes in
its associated BrowsingContextGroup for a set of SessionStoreState objects,
each of which correspond to a BrowsingContext in the tree that is being
flushed. These objects are generally constructed in the same way as they were
before, except now each corresponds to a single frame, instead of a full
document tree. - When the queries resolve, we build SessionStoreUpdateDatas out of the
results and send those to JS. The changes in SessionStoreFunctions.jsm
build the tree-like thing that SessionStore is familiar with.
Depends on D89223
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Kashav, is there more follow-up expected for this, after the current patches?
Comment 11•4 years ago
|
||
(In reply to Neha Kochar [:neha] from comment #10)
Kashav, is there more follow-up expected for this, after the current patches?
Yes, see https://phabricator.services.mozilla.com/D89224#inline-510327. SessionStore currently relies on a browser object for pretty much everything. The changes make it so we no longer have this object where we previously did. We might be able to find a workaround, but we'll probably need to update SessionStore to not depend on the browser object anymore (I'm unsure how long this will take, but I think it's farily involved).
Updated•4 years ago
|
Comment 12•4 years ago
|
||
This ensures that the embedder is kept alive as long as its BrowsingContext is
also alive. This helps get around frontend issues where a browser element would
no longer be available after its tab was closed.
Depends on D89223
Comment 13•4 years ago
|
||
We've changed the lifetime of the browser element, so it may outlive its
ownerGlobal. This prevents warnings/errors for property accesses on undefined
ownerGlobals.
Depends on D90705
Updated•4 years ago
|
Comment 14•4 years ago
|
||
If we saw a "TabClose" event prior to the completion of the flush, we would've
saved the cached tab data at the time of closing, which is now stale. This
overwrites any state that was saved with more recent tab data.
Depends on D89224
Comment 15•4 years ago
|
||
Comment on attachment 9173789 [details]
Bug 1572084 - Part 1: Move nsIDocShell::CreatedDynamically to BrowsingContext, r?kmag
Revision D89223 was moved to bug 1666485. Setting attachment 9173789 [details] to obsolete.
Comment 16•4 years ago
|
||
Discussed with Nika and Kashav:
This doesn't necessarily block the Nightly experiment and this needs some more time to be implemented correctly.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 18•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 20•4 years ago
|
||
Make it possible to skip sub-trees in traversals, and abort traversals
entirely.
Assignee | ||
Comment 21•4 years ago
|
||
Instead of collecting data from the entire tree of documents, we
collect data per document. The collected data is sent to the
corresponding parent window context and is applied incrementally to
the tab state cache.
Depends on D107813
Assignee | ||
Comment 22•4 years ago
|
||
All tests in browser/components/sessionstore/test
pass locally with Fission turned off.
A fresh new try is running at https://treeherder.mozilla.org/#/jobs?repo=try&revision=75069be4dc806735a746a1684a6f40fd845379c8
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 23•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 24•4 years ago
|
||
Comment on attachment 9208711 [details]
Bug 1572084 - Part 1: Skip default single select values. r=nika
Revision D108202 was moved to bug 1698446. Setting attachment 9208711 [details] to obsolete.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 25•4 years ago
|
||
When FrameLoader.requestTabStateFlush returns a promise instead of
handling resolve by calling TabStateFlusher.resolve we add a promise
we can race against to be able to cancel all pending flushes for a
browser.
Depends on D107814
Assignee | ||
Comment 26•4 years ago
|
||
Depends on D108472
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 27•4 years ago
|
||
Neha asked me to look at these leaks a bit. For at least one nsGlobalWindowInner I looked at, the issue was that the WindowGlobalChild was holding the window alive. In the second to last CC, the window global child was not present in the CC log at all, and there was one missing reference. In the final CC, where the window did get freed, there was exactly one more reference visible, and it was WindowGlobalChild::mWindowGlobal.
As for the WindowGlobalChild, it had a single reference, a SessionStoreDataCollector. Both appeared in the first CC, and there was a missing reference to the SessionStoreDataCollector holding them alive. Maybe the timer isn't getting cancelled immediately when the page closes?
Comment 28•4 years ago
|
||
SessionStoreDataCollector::mTimer is in the list of cycle collected fields, but timer are not cycle collected because they are used on multiple threads, so that won't actually do anything. I saw there was some Flush() method that might clear out the timers, but maybe that isn't working?
Assignee | ||
Comment 29•4 years ago
|
||
Thanks for the help! So turns out that the solution is to clear the collector out when WindowGlobalChild gets its destroy. Keeping cycles with WindowGlobalChild participating and relying on the CC is apparently a bad idea :(
I'm insanely happy to have resolved the leak though. Big thanks again.
Assignee | ||
Comment 30•4 years ago
|
||
We need a call to nsFrameLoader::RequestTabStateFlush to flush the
toplevel context first. That way we can ensure that session storage is
flushed consistently.
Updated•4 years ago
|
Comment 31•4 years ago
|
||
Comment 32•4 years ago
|
||
Backed out 3 changesets (bug 1572084) for WindowGlobalParent.cpp related failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/26082a39ec6371d911af53e971fb736434a20667
Failure log: https://treeherder.mozilla.org/logviewer?job_id=334431722&repo=autoland&lineNumber=3797
...
[task 2021-03-25T16:28:07.194Z] 16:28:07 INFO - GECKO(2604) | Finished test http://mochi.test:8888/browser/gfx/layers/apz/test/mochitest/helper_fission_animation_styling_in_transformed_oopif.html
[task 2021-03-25T16:28:07.295Z] 16:28:07 INFO - GECKO(2604) | AddressSanitizer:DEADLYSIGNAL
[task 2021-03-25T16:28:07.295Z] 16:28:07 INFO - GECKO(2604) | =================================================================
[task 2021-03-25T16:28:07.295Z] 16:28:07 ERROR - GECKO(2604) | ==2604==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001a8 (pc 0x7ff52d7bf278 bp 0x7ffcb8e45450 sp 0x7ffcb8e45440 T0)
[task 2021-03-25T16:28:07.295Z] 16:28:07 INFO - GECKO(2604) | ==2604==The signal is caused by a READ memory access.
[task 2021-03-25T16:28:07.296Z] 16:28:07 INFO - GECKO(2604) | ==2604==Hint: address points to the zero page.
[task 2021-03-25T16:28:07.839Z] 16:28:07 INFO - GECKO(2604) | #0 0x7ff52d7bf278 in mozilla::dom::WindowGlobalParent::GetRootOwnerElement() /builds/worker/checkouts/gecko/dom/ipc/WindowGlobalParent.cpp
[task 2021-03-25T16:28:07.841Z] 16:28:07 INFO - GECKO(2604) | #1 0x7ff52d7bf44b in mozilla::dom::WindowGlobalParent::UpdateSessionStore(mozilla::Maybe<mozilla::dom::sessionstore::FormData> const&, mozilla::Maybe<nsPoint> const&, unsigned int) /builds/worker/checkouts/gecko/dom/ipc/WindowGlobalParent.cpp:1188:27
[task 2021-03-25T16:28:07.842Z] 16:28:07 INFO - GECKO(2604) | #2 0x7ff52d7c1c0a in mozilla::dom::WindowGlobalParent::RecvUpdateSessionStore(mozilla::Maybe<mozilla::dom::sessionstore::FormData> const&, mozilla::Maybe<nsPoint> const&, unsigned int) /builds/worker/checkouts/gecko/dom/ipc/WindowGlobalParent.cpp:1279:7
[task 2021-03-25T16:28:07.859Z] 16:28:07 INFO - GECKO(2604) | #3 0x7ff528659cd3 in mozilla::dom::PWindowGlobalParent::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PWindowGlobalParent.cpp:1554:62
[task 2021-03-25T16:28:07.895Z] 16:28:07 INFO - GECKO(2604) | #4 0x7ff5281c202a in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) /builds/worker/workspace/obj-build/ipc/ipdl/PContentParent.cpp:6524:32
[task 2021-03-25T16:28:07.913Z] 16:28:07 INFO - GECKO(2604) | #5 0x7ff527fcefe9 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:2154:25
[task 2021-03-25T16:28:07.914Z] 16:28:07 INFO - GECKO(2604) | #6 0x7ff527fcc406 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:2078:9
[task 2021-03-25T16:28:07.915Z] 16:28:07 INFO - GECKO(2604) | #7 0x7ff527fcd62e in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1926:3
[task 2021-03-25T16:28:07.917Z] 16:28:07 INFO - GECKO(2604) | #8 0x7ff527fcddab in mozilla::ipc::MessageChannel::MessageTask::Run() /builds/worker/checkouts/gecko/ipc/glue/MessageChannel.cpp:1957:13
[task 2021-03-25T16:28:07.918Z] 16:28:07 INFO - GECKO(2604) | #9 0x7ff526ea43c6 in mozilla::RunnableTask::Run() /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:470:16
[task 2021-03-25T16:28:07.919Z] 16:28:07 INFO - GECKO(2604) | #10 0x7ff526ea0fd3 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:754:26
[task 2021-03-25T16:28:07.920Z] 16:28:07 INFO - GECKO(2604) | #11 0x7ff526e9eea7 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:609:15
[task 2021-03-25T16:28:07.921Z] 16:28:07 INFO - GECKO(2604) | #12 0x7ff526e9f2fd in mozilla::TaskController::ProcessPendingMTTask(bool) /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:393:36
[task 2021-03-25T16:28:07.922Z] 16:28:07 INFO - GECKO(2604) | #13 0x7ff526eab6f1 in operator() /builds/worker/checkouts/gecko/xpcom/threads/TaskController.cpp:133:37
[task 2021-03-25T16:28:07.923Z] 16:28:07 INFO - GECKO(2604) | #14 0x7ff526eab6f1 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_3>::Run() /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.h:534:5
[task 2021-03-25T16:28:07.932Z] 16:28:07 INFO - GECKO(2604) | #15 0x7ff526ec6b84 in nsThread::ProcessNextEvent(bool, bool*) /builds/worker/checkouts/gecko/xpcom/threads/nsThread.cpp:1155:16
[task 2021-03-25T16:28:07.933Z] 16:28:07 INFO - GECKO(2604) | #16 0x7ff526ed12dc in NS_ProcessNextEvent(nsIThread*, bool) /builds/worker/checkouts/gecko/xpcom/threads/nsThreadUtils.cpp:548:10
[task 2021-03-25T16:28:07.934Z] 16:28:07 INFO - GECKO(2604) | #17 0x7ff527fd4c3a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /builds/worker/checkouts/gecko/ipc/glue/MessagePump.cpp:87:21
[task 2021-03-25T16:28:07.939Z] 16:28:07 INFO - GECKO(2604) | #18 0x7ff527efed71 in RunInternal /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:335:10
[task 2021-03-25T16:28:07.940Z] 16:28:07 INFO - GECKO(2604) | #19 0x7ff527efed71 in RunHandler /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:328:3
[task 2021-03-25T16:28:07.941Z] 16:28:07 INFO - GECKO(2604) | #20 0x7ff527efed71 in MessageLoop::Run() /builds/worker/checkouts/gecko/ipc/chromium/src/base/message_loop.cc:310:3
[task 2021-03-25T16:28:07.949Z] 16:28:07 INFO - GECKO(2604) | #21 0x7ff52df30c07 in nsBaseAppShell::Run() /builds/worker/checkouts/gecko/widget/nsBaseAppShell.cpp:137:27
[task 2021-03-25T16:28:07.952Z] 16:28:07 INFO - GECKO(2604) | #22 0x7ff53153e487 in nsAppStartup::Run() /builds/worker/checkouts/gecko/toolkit/components/startup/nsAppStartup.cpp:273:30
[task 2021-03-25T16:28:07.953Z] 16:28:07 INFO - GECKO(2604) | #23 0x7ff53174549f in XREMain::XRE_mainRun() /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5346:22
[task 2021-03-25T16:28:07.954Z] 16:28:07 INFO - GECKO(2604) | #24 0x7ff5317479c6 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5537:8
[task 2021-03-25T16:28:07.955Z] 16:28:07 INFO - GECKO(2604) | #25 0x7ff531748983 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /builds/worker/checkouts/gecko/toolkit/xre/nsAppRunner.cpp:5600:21
[task 2021-03-25T16:28:07.959Z] 16:28:07 INFO - GECKO(2604) | #26 0x5643ca567a12 in do_main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:220:22
[task 2021-03-25T16:28:07.960Z] 16:28:07 INFO - GECKO(2604) | #27 0x5643ca567a12 in main /builds/worker/checkouts/gecko/browser/app/nsBrowserApp.cpp:347:16
[task 2021-03-25T16:28:08.027Z] 16:28:08 INFO - GECKO(2604) | #28 0x7ff54adfcb96 in __libc_start_main /build/glibc-2ORdQG/glibc-2.27/csu/../csu/libc-start.c:310
[task 2021-03-25T16:28:08.027Z] 16:28:08 INFO - GECKO(2604) | #29 0x5643ca4baa3c in _start (/builds/worker/workspace/build/application/firefox/firefox+0x55a3c)
[task 2021-03-25T16:28:08.027Z] 16:28:08 INFO - GECKO(2604) | AddressSanitizer can not provide additional info.
[task 2021-03-25T16:28:08.027Z] 16:28:08 INFO - GECKO(2604) | SUMMARY: AddressSanitizer: SEGV /builds/worker/checkouts/gecko/dom/ipc/WindowGlobalParent.cpp in mozilla::dom::WindowGlobalParent::GetRootOwnerElement()
[task 2021-03-25T16:28:08.027Z] 16:28:08 INFO - GECKO(2604) | ==2604==ABORTING
[task 2021-03-25T16:28:08.069Z] 16:28:08 INFO - GECKO(2604) | Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=4.2288) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
[task 2021-03-25T16:28:08.069Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.069Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.108Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.113Z] 16:28:08 INFO - GECKO(2604) | Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=81.714) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
[task 2021-03-25T16:28:08.114Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.115Z] 16:28:08 INFO - GECKO(2604) | Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=83.2024) [GFX1-]: Receive IPC close with reason=AbnormalShutdown
[task 2021-03-25T16:28:08.115Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.117Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.117Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.117Z] 16:28:08 INFO - GECKO(2604) | Exiting due to channel error.
[task 2021-03-25T16:28:08.214Z] 16:28:08 INFO - TEST-INFO | Main app process: exit 0
....
Comment 33•4 years ago
|
||
Updated•4 years ago
|
Comment 34•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d1526feb0024
https://hg.mozilla.org/mozilla-central/rev/018c3b393593
https://hg.mozilla.org/mozilla-central/rev/c48e578a03e9
Description
•