[RESOLVED] NoScript + Firebug = massive memory leak

[DavidCG]

I've been seeing a memory leak for the last couple of weeks - not exactly sure when it started. I've tracked down the cause to being NoScript + Firebug. It happens in daily use but the SunSpider test - http://www.webkit.org/perf/sunspider/sunspider.html - is a good trigger.

Here are results from running SunSpider - 'Private Bytes' as reported by Process Explorer:

1st run = 535,000
2nd run = 800,000
3rd run = 1,016,000
4th run = 1,226,000

With either NoScript or Firebug disabled this does not happen and memory is released and returns to 260,000. In daily use the memory keeps climbing until the browser becomes unresponsive and I need to restart.

Windows 7 + Fx Nightly + NoScript 2.1.1.2rc3 + Firebug 1.8.0b2 (http://getfirebug.com/releases/firebug/1.8/)

[Giorgio Maone]

Did you open a bug report in Mozilla's bugtracker?

[DavidCG]

No. Would they not say it's a problem with NoScript / Firebug?

Also memory use is far higher while the SunSpider test is running when NoScript is installed / enabled.

[Giorgio Maone]

No. Would they not say it's a problem with NoScript / Firebug?

Not necessarily.
Both the extensions exercise components of the Gecko platform which are not exercised by the browser itself nor by other popular extensions (NoScript is the main and almost unique client of CAPS, Firebug is the main and almost unique client of the JS debugging API).

Therefore, for instance, an interaction between CAPS and the debugging API which triggers a memory leak would happen only if NoScript and Firebug are both installed, but would be a Firefox bug.

Also memory use is far higher while the SunSpider test is running when NoScript is installed / enabled.

This is not unexpected: benchmarks need to repeat many times in a very short timespan tasks which otherwise would be nearly instantaneous, in order to measure them accurately.
If some of these task requires NoScript to perform a check, and during this check NoScript creates one or two objects, this otherwise modest memory occupation will be multiplied by many times in a timespan too short for the garbage collector to kick in and dispose the already "dead" objects.

[Giorgio Maone]

Side note: for instance, it might be https://bugzilla.mozilla.org/show_bug.cgi?id=646575

Both Firebug and NoScript use Sandboxes (NoScript uses them for surrogates).
Since Firebug, IIRC, creates at least an iframe for each page loaded in the browser, and surrogates are run on each page and subframe, Firebug's presence multiplies the surrogate execution.

If the Sandbox leak is triggered, this could create your problem.

Does disabling surrogates (noscript.surrogate.enabled -> false in about:config) help?

[dhouwn]

Here some helpful meta-bugreports (bugreports pointing to bug-reports with something in common), maybe the issue already reported there:

• [meta] memory size reductions for Firefox 5+
• [meta] Leaks and quasi-leaks reported against Firefox 6
• [meta] Leaks and quasi-leaks reported against Firefox 7

The Mozilla devs will probably want from you create a simple test case which in this case would be a simple what-to-do list on when starting from an empty profile and a description on which versions it happens, then they will probably want from you that you post the contents of the improved about:memory interface from Firefox 6+.

[DavidCG]

Does disabling surrogates (noscript.surrogate.enabled -> false in about:config) help?

It helps - but does not fix the problem.

Here are memory readings (in 1000 kbs) after each SunSpider run: 380, 420, 456, 473, 496

Thanks for the explanation and bug report. I'll take a look tomorrow and raise a new bug or add details to an existing one.

dhouwn, thanks for those bug reports. I'll take a look at those as well.

[Giorgio Maone]

Does disabling surrogates (noscript.surrogate.enabled -> false in about:config) help?

It helps - but does not fix the problem.

Please set the noscript.toStaticHTML about:config preference to false as well.

[DavidCG]

Please set the noscript.toStaticHTML about:config preference to false as well.

That helped by significantly reducing memory usage while running the test - but memory still crept up: 338, 385, 429, 470

[GµårÐïåñ]

A similar claim was made BUG 639186 and there was some discussion that might help, not sure if they are deeply connected issues but it might shed some light.

[DavidCG]

Apologies for vanishing. Real Life got in the way.

I've just retested with latest nightly and I'm no longer seeing the problem. I'll run with Firebug + NoScript enabled and see if the leak happens with daily browsing. I'll report back and open a ticket if it does.

[GµårÐïåñ]

Apologies for vanishing. Real Life got in the way.

That's ok, its understandable.

I've just retested with latest nightly and I'm no longer seeing the problem. I'll run with Firebug + NoScript enabled and see if the leak happens with daily browsing. I'll report back and open a ticket if it does.

Glad the problem is resolved, keep us posted if you find anything new.