e10s test bugs block e10s, but not a particular milestone.
tracking-e10s: --- → +
Created attachment 8518972 [details] [diff] [review] Minimal test case I've created a minimal test case that consistently leaks on my machine. It registers a shutdown callback, opens a tab, then calls finish(), after which the tab is removed by the shutdown callback. I have no idea what causes the leak, so if anyone has any idea what might be going on, please let me know. This is a rather big deal for us, as it likely causes all our debugger tests to leak on e10s debug builds.
4 years ago
Andrew, can you look at this?
(In reply to Andrew McCreight [:mccr8] from comment #5) > sure Thanks for taking this! This is blocking us from enabling a lot of the devtools tests on e10s debug builds, so its quite a priority for us. If there's anything I can do to help, let me know.
The particular failures I am seeing are: TEST-UNEXPECTED-FAIL | browser/devtools/debugger/test/browser_dbg_e10s.js | leaked 4 window(s) until shutdown [url = about:blank] TEST-UNEXPECTED-FAIL | browser/devtools/debugger/test/browser_dbg_e10s.js | leaked 2 window(s) until shutdown [url = chrome://mochitests/content/browser/browser/devtools/debugger/test/doc_e10s.html] TEST-UNEXPECTED-FAIL | browser/devtools/debugger/test/browser_dbg_e10s.js | leaked 2 docShell(s) until shutdown This is from the window leak checker that matches up ++DOMWINDOW and --DOMWINDOW (and for doc shells). I need to look at it some more, but it seems like maybe it treats windows that are destroyed after "TEST-START | Shutdown" as leaking, and we seem to not run the cycle collector at all until after that point, which would explain why nothing is destroyed. In non-e10s mode, we run the CC 3 or 4 times prior to that, so we clean up the window.
There are four CCs while we're starting to shut down, but before the "TEST-START | Shutdown". The first one is a memory-pressure CC. That does get propagated to the child, but not until after the "TEST-START | Shutdown". But I think that's a minor problem. The next three CCs are from the CCAnalyzer. In e10s mode, they still trigger CCs, but only in the parent process. So, that's bad from the perspective of causing these false positives, but it is also bad from the perspective that we're not running the CCAnalyzer leak checker in content, if I understand this correctly. Basically it looks like at the moment we run the ++/--DOMWINDOW stuff for both parent and child, but the CCAnalyzer stuff only in the parent, and the former just happens to depend on the latter running in the same process.
I filed bug 1096614. I think that will incidentally fix this issue, but it is a different enough symptom we should have different bugs for it.
Actually, I'll just dupe this over, because I think it is the same issue as bug 1073352.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1073352
You need to log in before you can comment on or make changes to this bug.