InformAction Forums

Starting around NoScript 2.6.8.37, NoScript seems to slowly leak memory for me in long-running, actively used Firefox sessions, ie when I leave Firefox running and open new windows/tabs to browse additional URLs over time (and closing the pages afterwards). This happens without having any JavaScript-using URLs left open over the long term (I basically only whitelist YouTube and I don't leave windows open on YT videos) and generally without any active JavaScript usage at all (I don't necessarily view YT videos all that often). The memory growth is big enough to be clearly visible; on 64-bit Linux, the resident set size will rise from 700 MB or so on a recently started Firefox up to over 1.5 GB in a day or so of active usage (opening URLs in new windows, reading the pages, and then closing them again). This happens in both Firefox 32 and the latest Nightly builds.

I went back to old versions to test and NoScript 2.6.8.35 seems more or less stable. 2.6.8.36 seems either stable or close to stable, with at most very very slow memory growth over time. 2.6.8.37 shows relatively rapid and sizable memory growth for me; versions since then seem to have reduced the memory growth rate but it remains present right through the lastest version available (2.6.8.41 as I write this; I've checked for a subsequent development version but haven't seen one). I've also tested disabling both NoScript and JavaScript itself, which gives me a stable (and noticably smaller) memory usage in my usual long term session.

(I haven't tested the intermediate rc versions between these, although I can if it would be useful.)

I'm using other extensions as well so it's possible that this is specific to NoScript's interactions with them. My current set of extensions are CipherFox, CookieSafe 3.1.1, FireGestures, Flashblock, It's All Text!, Open in Browser, the Mozilla JS PDF Viewer, and StopTube (all of them the latest versions except CookieSafe, where later versions have or had a fatal interaction with NS).

(I have NS configured to not block Flash; I rely on FlashBlock for that for reasons beyond the scope of this bug report. I have not tested disabling FlashBlock and relying on NS's Flash blocking, although I can if people think that that might be the issue.)

cks wrote:(I haven't tested the intermediate rc versions between these, although I can if it would be useful.)

If Giorgio doesn't respond within 36 hours or so, yes that would be useful.

Anything in about:memory that you can point to/show, like "zombie compartments"?
(Not that I know how to interpret that stuff.)

I've now gone through several rc versions and as far as I can tell the leaks start in 2.6.8.37rc3, while rc1 and rc2 are fine (testing takes a while since leaks are only clearly obvious after at least several hours to most of a day of active use).

I've now taken a look at about:memory's detailed information (for 2.6.8.37rc3) and I can't spot any lingering compartments that are obviously out of place. In general nothing about about:memory's reporting stands out to me, although I'm not exactly an expert. I've now saved a verbose about:memory memory report from my 2.6.8.37rc3 session (and will try and save 2.6.8.42rc1, since that's now out).

Does about:addons-memory show this "leak" as part of the browser or NS?

I don't normally run about:addons-memory but I've just restarted in an environment where I can use it and I'll report in on what it says for NS 2.6.8.42rc1. My memory from when I tried looking at it before is that the extra memory usage didn't show up in the NoScript section (and that a:a-m's 'minimize memory usage' button did nothing to affect it). This is intuitively what I expected, since a:a-m's note implies that only some addon memory usage can be captured by it.

(a:a-m doesn't work in recent Firefox Nightlies because FF has changed something about the memory reporting interface, and I normally run more or less recent FF Nightlies. I've now switched back to a FF 32 build, which a:a-m does work in.)

I've now run long enough to be sure, so I can say that 2.6.8.42rc1 has the leak problem and about:addons-memory shows nothing directly; at the moment (with FF having grown from ~500 MB to over 1 GB resident set size) it says NoScript is using 2.55 MB.

I believe I've now identified the specific change that causes NoScript to grow Firefox's memory usage for me. It appears to be the 2.6.8.37rc2 to rc3 change to chrome/content/noscript/noscriptOverlay.js (which I believe probably corresponds to the changelog item of 'NoScript's toolbar button is now friendlier to other Australis-enabled add-ons'). As a test of this I am currently running a hacked up version of NS 2.6.8.43 with the .43 noscriptOverlay.js replaced with the 2.6.8.37rc2 version and I am seeing no memory growth.

I don't know enough Javascript (or Firefox extension programming) to have any idea about why this specific section of code would cause memory leakage problems, but there you go. I would be happy to test variants of this code if people tell me what to change (or give me test versions).

(My manual hand bisection did not wind up testing 2.6.8.37rc3 with the rc2 noscriptOverlay.js, because I started with the assumption that the largest chunk of changes were probably the culprit. This turned out to be wrong, so I've only tested 2.6.8.37rc2 plus the chrome/content/noscript/noscriptBM.js change; that definitely didn't leak memory for me.)

For reference: So you're saying that's the change that caused the leak?
Does the leak happen in SeaMonkey (if you can test; if not, what should SeaMonkey users like me look for / how could we easily tell on a profile that can uses a lot of memory anyway)?
If reversing that patch on latest development build doesn't bork NoScript, does the leak stop then?

Yes, that's the change. Right now, 2.6.8.43 is the latest build available (the dev builds are older) and reverting it to the 2.6.8.37rc2 version of noscriptOverlay.js both appears to work fine and does not leak memory for me.

(You can't literally revert the patch because at some point between 2.6.8.37rc3 and 2.6.8.43 an additional noscriptOverlay.js change was also made to this section.)

I don't know if this reproduces on SeaMonkey or with anything other than my particular set of extensions. The way to test it would be to start SeaMonkey, park an idle SeaMonkey window somewhere so it never exits, look at the initial memory usage, browse various URLs for at least several hours, close all of the windows and tabs you opened during your browsing, and look at the new memory usage. For me this pattern shows drastic jumps in memory usage (especially Linux's Resident Set Size) with an unfixed NS and barely any change in memory with a fixed or non-problematic NS.

(I believe I have also seen a just-started Firefox instance use noticably more memory when NS has this issue than when it doesn't, but I haven't actually measured this; consider it an anecdotal report of something that you might notice, especially in a configuration where you start SeaMonkey with a lot of windows/tabs already opened.)

You could probably contrive a synthetic test by opening and then closing several hundred different URLs in a single session, possibly via automation to make it less tedious.

(I don't think the URLs need to have JavaScript enabled in NS, especially given that this issue seems related to setting up the toolbar.)

Please check latest development build 2.6.9rc1, thank you.

I've now had a chance to check out 2.6.9rc1 and unfortunately it still leaks for me. I didn't notice any change in how fast or slow the leak happened between 2.6.9rc1 and previous releases.

fx33.1.1 fresh profile with:
NoScript 2.6.9.5rc2
devtools.errorconsole.enabled;true
browser.startup.page;0

about:memory and Error Console open, Minimize memory usage Opening 3 windows, closing, Minimize memory usage Evaluatingin Error console frees top(none)/detached/window

Please check latest development build, thank you.

Sorry for the delay in reporting on this: NoScript 2.6.9.5 doesn't leak for me, so I think that this is solved. Thank you very much to everyone who helped work out what was going on and fix it.