Closed Bug 723832 Opened 12 years ago Closed 11 years ago

New Tab Page frequently leaks 4-700+Kb (AtomImpl + BackstagePass + DOMCSSDeclarationImpl + DOMCSSStyleRule + more) in mochitest-browser-chrome

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 750424
Tracking Flags:
Tracking Status
firefox13 - affected
firefox14 - affected

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure, memory-leak, regression, Whiteboard: [MemShrink:P1]) 

This leak exploded this morning on mozilla-inbound, and I wanted to pin it on the push after a merge from mozilla-central, because the merge was green and the next push had three instances of this leak, but I didn't have time during the day, and then bugmail about this same leak being misstarred as a crashtest leak alerted me that it was on mozilla-central before my blame-target had gotten there.

First seen on mozilla-central on https://hg.mozilla.org/mozilla-central/rev/1cdef0321abd (merge from fx-team), first seen on fx-team on https://hg.mozilla.org/integration/fx-team/rev/29c4463e6a2e (enable New Tab Page and what I presume are supporters, which are just as likely to be the real cause I suppose).

Retriggers in https://tbpl.mozilla.org/?tree=Fx-Team&rev=29c4463e6a2e show plenty more instances beside the one that was there from the initial push; retriggers on the parent in https://tbpl.mozilla.org/?tree=Fx-Team&rev=e7f7c1e948ca don't show any (gambling, because I still have a couple of retriggers running right this second, but the odds are with me).

Sorry, but, j'accuse.

http://tbpl.swatinem.de/php/getLeakAnalysis.php?id=9053424 (the working version of the "analyze the leak" links that are broken on tbpl.m.o) only mentions the lying not actually leaked domwindow from test_process_error.xul, so unfortunately there's no help about which test is triggering the leak, other than "something in browser-chrome" (and "not test_process_error.xul, which isn't even in browser-chrome").
https://tbpl.mozilla.org/php/getParsedLog.php?id=9056354&tree=Mozilla-Inbound
Summary: New Tab Page frequently leaks 700+Kb (AtomImpl + BackstagePass + DOMCSSDeclarationImpl + DOMCSSStyleRule + more) in mochitest-browser-chrome → New Tab Page frequently leaks 4-700+Kb (AtomImpl + BackstagePass + DOMCSSDeclarationImpl + DOMCSSStyleRule + more) in mochitest-browser-chrome
I'm optimistic about this being fixed by bug 723102 - we accidentally hold New Tab Pages alive by the JSM (instead of properly unregistering them). Will land today.
Depends on: 723102
Marking as fixed by bug 723102.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
https://tbpl.mozilla.org/php/getParsedLog.php?id=9230791&tree=Mozilla-Aurora (a couple of pushes after you flipped the pref on aurora) reminds me a great deal of this, so I think you might have had another thing involved in the leak fix, that didn't hit aurora.
(In reply to Phil Ringnalda (:philor) from comment #28)
> https://tbpl.mozilla.org/php/getParsedLog.php?id=9230791&tree=Mozilla-Aurora
> (a couple of pushes after you flipped the pref on aurora) reminds me a great
> deal of this, so I think you might have had another thing involved in the
> leak fix, that didn't hit aurora.

Yeah, but I don't have a clue what changeset fixed that entirely. Need to look what landed around the same time.
https://tbpl.mozilla.org/php/getParsedLog.php?id=10084544&tree=Mozilla-Inbound

Sure was nice having this gone for a while, back when it was gone for a while.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
status-firefox13: --- → affected
Nominating for tracking because it is a fairly large, fairly frequent leak apparently introduced by a new feature.
status-firefox14: --- → affected
tracking-firefox13: --- → ?
tracking-firefox14: --- → ?
Whiteboard: [orange] → [orange][MemShrink]
(In reply to Andrew McCreight [:mccr8] from comment #60)
> Nominating for tracking because it is a fairly large, fairly frequent leak
> apparently introduced by a new feature.

This is reasonable - also sending over to Tim since we suspect this to be related to the new tab page.
Assignee: nobody → ttaubert
tracking-firefox13: ? → +
tracking-firefox14: ? → +
Whiteboard: [orange][MemShrink] → [orange][MemShrink:P1]
What's happening here?  This is a significant leak in a new feature.
(In reply to Tim Taubert [:ttaubert] from comment #38)
> (In reply to Phil Ringnalda (:philor) from comment #28)
> > https://tbpl.mozilla.org/php/getParsedLog.php?id=9230791&tree=Mozilla-Aurora
> > (a couple of pushes after you flipped the pref on aurora) reminds me a great
> > deal of this, so I think you might have had another thing involved in the
> > leak fix, that didn't hit aurora.
> 
> Yeah, but I don't have a clue what changeset fixed that entirely. Need to
> look what landed around the same time.

This appears to still be a problem on FF13 and up. What are the next steps for this investigation?
I'm kind of hoping that this was fixed by bug 750424. It hasn't happened on inbound since that patch landed, but with the tree closed there haven't been enough pushes to say for sure.
I'm going to call this fixed.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → DUPLICATE
(In reply to Bill McCloskey (:billm) from comment #150)
> I'm kind of hoping that this was fixed by bug 750424. It hasn't happened on
> inbound since that patch landed, but with the tree closed there haven't been
> enough pushes to say for sure.

We'll track bug 750424 instead in that case. Thanks!
tracking-firefox13: + → -
tracking-firefox14: + → -
Blocks: 764771
No longer blocks: 764771
Whiteboard: [orange][MemShrink:P1] → [MemShrink:P1]
Assignee: ttaubert → nobody
You need to log in before you can comment on or make changes to this bug.