Perma leak while running accessible/tests/browser/e10s/browser_treeupdate_removal.js with Fission on Windows
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox90 | --- | affected |
People
(Reporter: mccr8, Unassigned)
References
Details
(Whiteboard: probably [not-a-fission-bug])
I was running Fission tests in a Windows 10 x64 WebRender debug build, which apparently isn't normally done, and I noticed there's a permaleak while running accessible/tests/browser/e10s/browser_treeupdate_removal.js (it shows up here in bc6): https://treeherder.mozilla.org/jobs?repo=try&revision=bae74ccccea37ceb2cf53f156dfc1f1bfec287df
The steps I took to determine what test was running:
- Go to the part of the Mochitest log where the failure is shown:
TEST-UNEXPECTED-FAIL | leakcheck | tab 1240 bytes leaked (AccessibleWrap, HTMLTableAccessible, HTMLTableAccessibleWrap, HyperTextAccessible, HyperTextAccessibleWrap, ...)
- Go back to the part in the log before the ASCII chart that says what the name of the log is where the leak happened:
leakcheck | Processing leak log file c:\users\task_1619484273\appdata\local\temp\tmp7xquvy.mozrunner\runtests_leaks_tab_pid9636.log
- From there, I searched backwards in the Mochitest log for the name of the leak log (runtests_leaks_tab_pid9636.log in this case) to find where it was being created:
### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to c:\users\task_1619484273\appdata\local\temp\tmpiihn1a.mozrunner\runtests_leaks_tab_pid9636.log
- From there, I backtracked a bit to find the test that was running when this log was created:
TEST-START | accessible/tests/browser/e10s/browser_treeupdate_removal.js
Across the 6 failures, the leaking process was always being created during this test.
This leak looks like one that has shown up a few times in a11y code, and I think it is probably just some shutdown issue that isn't too important, but I figured I'd file it in case somebody is trying to fix an intermittent instance of this leak.
Updated•4 years ago
|
Comment 1•3 years ago
|
||
Jamie, Andrew saw this test perma leak when running these tests with Fission enabled. Do you think this bug could happen without Fission?
Comment 2•3 years ago
|
||
I'm not sure what's causing this, but I very much doubt it's Fission specific. It might be more likely with Fission due to timing, number/order of documents loaded in that process or something like that, but we don't seem to be leaking Fission specific objects here.
Bug 1665728 looks similar.
Updated•3 years ago
|
Description
•