InformAction Forums

Running a relatively current Firefox Nightly (although not so current that NoScript breaks), NoScript 2.6.9.37rc2 and 2.6.9.37 itself both leak memory at a moderate rate over a long running, actively used session. I leave Firefox running with a stable set of windows, none of them with JavaScript enabled, and then open and close a succession of transient windows (most of them with JS off). When I do this with 2.6.9.36, my memory use is stable and Firefox is responsive; when I do this with 2.6.9.37rc2+, Firefox memory usage steadily but slowly climbs and Firefox responsiveness becomes increasingly janky. I'm on 64-bit Linux (specifically Fedora 22).

(I'd test a copy of 2.6.9.37rc1, but unfortunately I can't get a copy of it via the Firefox addons site. Oh oops; I see it's available here. I've installed it and will report in once I can tell if it is or isn't leaking memory on me.)

e10 enabled?

Nightly?
Just where is that, currently, 44?

Is it about:memory that you go to check for "zombies" (compartments, or something of that nature)?

e10s disabled (it's incompatible with other extensions I use). Nightly current claims to be '44.0a1'.

I'm checking memory use with Unix 'top' and looking primarily at the 'RES' (resident set size). A freshly restarted Firefox on one machine will have a RSS around 350 MB under normal circumstances; with 2.6.9.37rc2+ this is larger and starts growing towards 900 MB and upwards as I use Firefox (opening and then closing windows).

My testing so far suggests that 2.6.9.37rc1 is not affected by this. I haven't looked at about:memory and Nightly doesn't seem to have an about:compartments any more.

(Generally beyond me, but...) MDN Zombie compartments.

I've now verified that 2.6.9.37rc1 does not leak for me and then narrowed the problem down to the _syncUIReal change in chrome/content/noscript/noscriptOverlay.js. A version of 2.6.9.37rc1 with all changes to .js files except that one does not leak. I'm about to try running a version of 2.6.9.38 with this change reverted, but I expect it to be stable too.

This change contains both the addition of a try/catch block and accesses of .QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDOMWindowUtils).currentInnerWinowID for both 'w' and 'content'. I'm not a JavaScript person, so I can't put together a version with just one of these two changes to see which leaks (or if it requires both together for some reason).