Open Bug 1707988 Opened 4 years ago Updated 3 years ago

Perma leak while running accessible/tests/browser/e10s/browser_treeupdate_removal.js with Fission on Windows

Categories

(Core :: Disability Access APIs, defect, P3)

defect

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:

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

Severity: -- → S3
Priority: -- → P3

Jamie, Andrew saw this test perma leak when running these tests with Fission enabled. Do you think this bug could happen without Fission?

Fission Milestone: --- → ?
Flags: needinfo?(jteh)

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.

Flags: needinfo?(jteh)
See Also: → 1665728
Fission Milestone: ? → ---
Whiteboard: probably [not-a-fission-bug]
You need to log in before you can comment on or make changes to this bug.