Closed Bug 1283262 Opened 5 years ago Closed 5 years ago
Complete E10S .jsm leaks windows
I got a leaked browser.xul in my nightly 50.0a1 (2016-06-29) today: │ ├───4.87 MB (02.38%) -- top(none)/detached │ │ ├──4.87 MB (02.38%) -- window(chrome://browser/content/browser.xul) │ │ │ ├──2.62 MB (01.28%) ++ js-compartment([System Principal], about:blank) │ │ │ └──2.26 MB (01.10%) ++ (3 tiny) │ │ └──0.00 MB (00.00%) ── window([system])/dom/other Looking at the CC logs its being leaked through AutoCompleteE10S.jsm: Parsing cc-edges.8716.1467228425.log. Done loading graph. 0000023C93066060 [JS Object (Window)] --[UnwrapDOMObject(obj)]--> 0000023C9B310000 [nsGlobalWindow # 145 inner chrome://browser/conten t/browser.xul] Root 0000023C93066060 is a marked GC object. bkelly@kosh /c/devel/tmp/cclogs/20160629-browser-xul $ /c/devel/heapgraph/find_roots.py gc-edges.8716.1467228425.log -bro 0000023C93066060 Parsing gc-edges.8716.1467228425.log. Done loading graph. via persistent-Object : 0000023C87EB6CE0 [BackstagePass 23c894db280] --[AutoCompleteE10S]--> 0000023C930AB080 [Object <no private>] --[_popupCache]--> 0000023C97B8BD80 [Object <no private>] --[browserWindow]--> 0000023C9817B3A0 [Proxy <no private>] --[private]--> 0000023C9307D040 [Proxy <no private>] --[private]--> 0000023C93066060 [Window <no private>] Unfortunately I don't know what I did to trigger this. Blake, you touched this file last. What do you think?
I guess I'm not 100% sure if this is a regression or not.
Looking at the code, nothing seems to clear this._popupCache. Maybe there's also a similar problem with this.browser.
I have steps to reproduce this: 1) Open a new nightly browser instance 2) Open a example.com in a tab (to hold the child process alive) 3) Open about:memory in a tab 4) Open a new second window 5) Open a site with an address form (like usps.gov/umove wizard) in second window 6) Type some stuff into the address fields 7) Close the second window 8) Minimize and measure memory in about:memory tab 9) Observe that the second window has leaked
I hit this enough that I'm going to try to fix it.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
I think this is a 95% solution. It cleans up the cache when: 1) a user tabs out of an autocompleting form field \ 2) a user closes the tab while focused on a form field if there are other tabs open in the window It does not, however, fix the problem if the user closes the entire window while focused on a form field. I've had a lot of trouble trying to get the message manager to send its message in that case.
Try build (although treeherder is broken at the moment): https://treeherder.mozilla.org/#/jobs?repo=try&revision=4bfec9520a9c
The 100% solution. Just listen for the browser unload event and clear the cache.
Attachment #8772167 - Attachment is obsolete: true
Comment on attachment 8772399 [details] [diff] [review] P1 Make AutomCompleteE10S clear its popup cache when the associated browser window is closed. r=mrbkap This patch simply clears the _popupCache when the associated browser is unloaded. I tried to write a test for this but I can't seem to trigger the AutoCompleteE10S code in a new window in a browser chrome test. Any suggestions on how to do this are welcome. I may just land this without a new test, though.
Attachment #8772399 - Flags: review?(mrbkap)
Attachment #8772399 - Flags: review?(mrbkap) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/4de50147d99c Make AutoCompleteE10S clear its popup cache when the associated browser window is closed. r=mrbkap
You need to log in before you can comment on or make changes to this bug.