Smart window leaks aiWindow.html if the window in which it is opened as a tab is not closed prior to the end of the test (suite)
Categories
(Core :: Machine Learning: Frontend, defect, P1)
Tracking
()
People
(Reporter: Gijs, Assigned: Mardak)
References
Details
(Whiteboard: [genai][switcher])
Attachments
(1 file)
Ran into this when trying to write a test. Minimal browser test that reproduces this:
add_task(async function test_leaky_leaky() {
AIWindow.toggleAIWindow(window, true);
await BrowserTestUtils.withNewTab(
{ url: AIWINDOW_URL, gBrowser, },
async browser => {
Assert.ok(true, "It's a test");
}
);
AIWindow.toggleAIWindow(window, false);
});
I tried to use CC logs as per https://firefox-source-docs.mozilla.org/performance/memory/leaked_until_shutdown.html but I don't see the window turning up in any CC logs except the one where it's garbage, at which one it can't find a path. The only reference at that point is the inner window, which in turn has an absolute tonne of references. So I'm a little lost.
Updated•15 hours ago
|
| Reporter | ||
Comment 1•15 hours ago
|
||
Ran into this in bug 2013950
Comment 2•15 hours ago
|
||
You could try getting the address of the DOM reflector (a JS object) from the log where the window is garbage, and then use the GC log from the prior GC to see why the DOM reflector is alive.
Comment 3•15 hours ago
|
||
Running with MOZ_CC_ALL_TRACES=all in addition to the other stuff might make the window show up earlier (but please don't delete your other logs until you figure out if it does something useful...)
| Reporter | ||
Comment 4•15 hours ago
|
||
heap graph output:
$ ~/heapgraph/find_roots.py cc-edges.120643-9.log 0x77d77a0a3400
Parsing cc-edges.120643-9.log. Done loading graph.
Didn't find a path.
known edges:
0x77d762b29200 [nsGlobalWindowInner # 27 inner chrome://browser/content/aiwindow/aiWindow.html] --[mOuterWindow]--> 0x77d77a0a3400
Comment 5•15 hours ago
|
||
You need to look up the object of the JS object in the prior GC log not the CC log. The corresponding GC log should be gc-edges.120643-9.log. You can use the same find_roots.py script because I have some hacks that look at the file name to figure out what to do.
| Reporter | ||
Comment 6•15 hours ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #5)
You need to look up the object of the JS object in the prior GC log not the CC log. The corresponding GC log should be
gc-edges.120643-9.log. You can use the same find_roots.py script because I have some hacks that look at the file name to figure out what to do.
Yeah, sorry - I just mid-aired with your comment, was trying to find the info from my terminal from when I did earlier debugging. Also intended to attach all the logs but looks like they're 80mb zip-r9'd so that's not happening.
For my context when I come back to this after sleep, how do I find the address for the DOM reflector for looking in the GC log? Or would the same address work? The docs linked in comment 0 use the CC log with find_roots...
Comment 7•14 hours ago
|
||
If you are looking for the DOM reflector for say 0x77d762b29200 you want to look in the CC log for a line like this:
> 0x77d762b29200 UnwrapDOMObject(obj)
Then keep scrolling up past lines that start with > to look for a line like
0x31daf0843030 [gc.marked] JS Object (Window)
That means that 0x31daf0843030 is the address of the JS reflector for the window 0x77d762b29200. Then you'd look up the JS object, ``0x31daf0843030` in the prior GC log.
| Assignee | ||
Comment 8•12 hours ago
|
||
the test doesn't leak if i return early before this.window.addEventListeners https://searchfox.org/firefox-main/rev/e7f79d7d80b01b4d4b4d961124ef960ba9ab30a7/browser/components/urlbar/content/SmartbarInput.mjs#427
looks like disconnectedCallback isn't getting called
| Assignee | ||
Comment 9•12 hours ago
|
||
explicitly unload to trigger disconnectedCallback
Comment 10•1 hour ago
|
||
Description
•