jst is seeing this when he runs e10s for a few days. There are 8 entries like this in about:memory │ ├────578.69 MB (09.74%) -- top(about:newtab, id=119) │ │ ├──576.70 MB (09.71%) -- active/window(about:newtab) │ │ │ ├──540.69 MB (09.10%) -- dom │ │ │ │ ├──540.60 MB (09.10%) ── orphan-nodes │ │ │ │ └────0.09 MB (00.00%) ++ (4 tiny) │ │ │ └───36.02 MB (00.61%) ++ (4 tiny) │ │ └────1.99 MB (00.03%) ++ js-zone(0x7fb9ec261800)

He said he doesn't have any addons. One thing that hopefully isn't playing a role is that he's running a DMD build, with DMD disabled. I think with a CC log we should be able to figure out what is going on, but when the leak gets this bad (6 gigs of RAM), getting the CC log just hangs the browser.

Is this in child or parent process? (I thought about:newtab runs in parent)

Yes, it's all in the parent.

Turns out I lied :( I do have some addons hanging around in this profile, specifically "Linky" and "Mass Password Reset". I have now disabled both of them.

It would be worth investigating if Linky is the problem, if you can't reproduce it otherwise. (Presumably you don't mass reset your passwords every day.)

My current theory is that the child process for thumbnailing is somehow interacting badly when we have regular e10s enabled, but that's just a hunch. Here's some directions for how to trigger that: https://blog.mozilla.org/nnethercote/2013/10/22/how-to-trigger-a-child-process-in-desktop-firefox/ I'll try investigating that angle when I get some time.

I'm doing some investigating of the logs here.

for investigation - m2

jst reports that disabling tab thumbnails does not help. I looked into this some more using a CC graph log from jst's session. There are about 3000 orphan DOM nodes (DOM nodes not in a document), in a bunch of little clumps of exactly 12 DOM nodes each. The topmost node in each of these little trees is a div element with class 'newtab-site'. There's some unknown thing that is holding a reference to the div that isn't visible to the cycle collector, which is odd. That seems to be what is holding it alive. It looks like this div element is the one being registered by the sponsored tile code. I don't know if that's related. http://mxr.mozilla.org/mozilla-central/source/browser/base/content/newtab/sites.js#189 jst has some kind of weird setup with X set to follow focus so maybe some focus event is getting dropped, or something like that.

Is this a runtime leak or shutdown leak? If the former, could we check what releases the div?

(In reply to Olli Pettay [:smaug] from comment #10) > Is this a runtime leak or shutdown leak? If the former, could we check what > releases the div? I think this is a runtime leak, but it might be a shutdown leak. It may not even be a leak, but just some kind of odd bloating. This is on jst's session, after he leaves it alone, so I'm not sure how easy it will be to check the release.

Last time jst had a leak like this it was caused by some kind of bandwidth-monitoring tab that he has open all the time. Could it be that again?

I don't think so, these seem to be orphan DOM nodes from the actual new tab page.

(In reply to Andrew McCreight [:mccr8] from comment #1) > He said he doesn't have any addons. One thing that hopefully isn't playing > a role is that he's running a DMD build, with DMD disabled. I think with a > CC log we should be able to figure out what is going on, but when the leak > gets this bad (6 gigs of RAM), getting the CC log just hangs the browser. 6G of RAM --- do you know how many vertices that is in the CC graph? The cycle collector used to silently bail out at 8M vertices. In bug 927705 that got raised to 64M vertices. 6G/64M is about 100 bytes, a reasonable size for a CC vertex. The bailing out takes place here: http://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsCycleCollector.cpp#2858 and other similar places in this file. There now is a CC_TELEMETRY(_OOM, true); there, which suggests that you might be able to check that in about:telemetry (?).

True, it will show up in about:telemetry as CYCLE_COLLECTOR_OOM, under histograms.

Moving to M3 milestone. These bugs affect e10s dogfooding but Brad and Gavin did not think they were M2 blockers.

mccr8 thinks this might be specific to jst's remote X set-up. Re-noming to push this out a bit.

No remote X setup here any more, this is running on a vanilla linux box, nothing special here AFAIK. It could still be unique to me, of course, but my setup is not at all far from what most people would see on linux (which didn't use to be the case).

jst said a while ago that he hadn't seen this in a long time.