1572084 - SessionStoreListener code tries to read layout and form data for windows loaded in a different child process

Status: RESOLVED FIXED

(Firefox :: Session Restore, defect, P1)

Description

[Alphan Chen [:alchen]]

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

Comment 1

[Andreas Farre [:farre]]

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?

Comment 2

[Alphan Chen [:alchen]]

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

[Peter Van der Beken [:peterv]]

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.

Comment 4

[Alphan Chen [:alchen]]

When enabling fission, "browser/components/sessionstore/test/browser_sessionStorage.js" is failed due to this bug.

Comment 5

[Chris Peterson [:cpeterson]]

M6c because we don't want to lose form data.

Comment 6

[u608768]

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?

Comment 7

[Nika Layzell [:nika] (ni? for response)]

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

1. 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.
2. 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.
3. 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.
4. 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 is true 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.

Comment 8

[u608768]

Attachment: Bug 1572084 - Part 1: Move nsIDocShell::CreatedDynamically to BrowsingContext, r?kmag

Comment 9

[u608768]

Attachment: Bug 1572084 - Part 3a: Make SessionStoreListener work for Fission, r?nika

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.

1. 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.
2. 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.
3. 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

Comment 10

[Neha Kochar [:neha]]

Kashav, is there more follow-up expected for this, after the current patches?

Comment 11

[u608768]

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

Comment 12

[u608768]

Attachment: Bug 1572084 - Part 2a: Don't clear BrowsingContext::EmbedderElement if it's not being replaced, r?nika

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

[u608768]

Attachment: Bug 1572084 - Part 2b: Add some null checks for the browser's ownerGlobal, r?nika

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

Comment 14

[u608768]

Attachment: Bug 1572084 - Part 3b: Ensure we update cached data for closed tabs, r?nika

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

[Phabricator Automation]

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

[Neha Kochar [:neha]]

Discussed with Nika and Kashav:
This doesn't necessarily block the Nightly experiment and this needs some more time to be implemented correctly.

Comment 18

[u608768]

Attachment: Bug 1572084 - Changes to D89224 DONTLAND

Comment 20

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 1: Add enhanced Browsing Context traversal. r=nika

Make it possible to skip sub-trees in traversals, and abort traversals
entirely.

Comment 21

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 2: Make Session Store data collection work with fission. r=nika

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

Comment 22

[Andreas Farre [:farre]]

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

Comment 23

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 1: Skip default single select values. r=nika

Comment 24

[Phabricator Automation]

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.

Comment 25

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 3: Add a cancel promise to TabStateFlusher. r=nika

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

Comment 26

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 4: Don't collect default single select values. r=nika

Depends on D108472

Comment 27

[Andrew McCreight [:mccr8]]

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

[Andrew McCreight [:mccr8]]

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?

Comment 29

[Andreas Farre [:farre]]

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.

Comment 30

[Andreas Farre [:farre]]

Attachment: Bug 1572084 - Part 3: Force session store flush order. r=nika

We need a call to nsFrameLoader::RequestTabStateFlush to flush the
toplevel context first. That way we can ensure that session storage is
flushed consistently.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5aa59e106a42
Part 1: Add enhanced Browsing Context traversal. r=nika
https://hg.mozilla.org/integration/autoland/rev/4d5a5ac074e6
Part 2: Make Session Store data collection work with fission. r=nika
https://hg.mozilla.org/integration/autoland/rev/d42a68132e7e
Part 3: Force session store flush order. r=nika

Comment 32

[Bogdan Tara[:bogdan_tara | bogdant]]

Backed out 3 changesets (bug 1572084) for WindowGlobalParent.cpp related failures.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=Ix3zHmieSj-bqptxZZivTA.0&fromchange=a05e8918c4daaec4c353ec09232c69942b90ad1d&searchStr=linux%2C18.04%2Cx64%2Casan%2Copt%2Cmochitests%2Ctest-linux1804-64-asan%2Fopt-mochitest-browser-chrome-e10s%2Cbc12&tochange=26082a39ec6371d911af53e971fb736434a20667

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

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d1526feb0024
Part 1: Add enhanced Browsing Context traversal. r=nika
https://hg.mozilla.org/integration/autoland/rev/018c3b393593
Part 2: Make Session Store data collection work with fission. r=nika
https://hg.mozilla.org/integration/autoland/rev/c48e578a03e9
Part 3: Force session store flush order. r=nika

Comment 34

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/d1526feb0024
https://hg.mozilla.org/mozilla-central/rev/018c3b393593
https://hg.mozilla.org/mozilla-central/rev/c48e578a03e9