InformAction Forums

I've been noticing lately that Firefox 3.5.1 seems to be using more and more memory the longer I have it open. This is the normal sign of a memory leak so I decided to install the Leak Monitor Extension to see if I could track down what was causing it.

The first thing I noticed is that it seemed like memory was being leaked every time I went to a new browser page. Closing windows was even worse. I disabled all my add-on and the problem went away (not entirely, but for the most part yes) so I started re-enabling them one at a time. When I enabled Noscript I started getting the "New Leak Alert" windows popping up when closing window, browsing to new sites and the like.

The vast majority of the time there is a "Reclaimed Leak" popup for each "leak alert" popup, indicated that the garbage collector managed to reclaim the memory, but it took it longer than it should have.

I once asked the author of Leak Monitor about these leak then reclaim alerts back in early 2008 and he said that "these alerts are a sign of a bug (probably in the Core) that we're taking multiple cycles of garbage collection to clean things up. With the cycle collector, it should only take one cycle. So we should really make these go away by fixing the underlying bugs."

Steps to reproduce:
1. Start browser and open a bunch of windows. The browser should have some kind of home page (preferably with javascript) so the windows aren't all blank.
2. Just start closing the newly opened windows.


Note I have other extensions leak a lot worse than NoScript or cause the leaks from Noscript to never be reclaimed, but I figured I'd post here since NoScript is at least temporarily leaking objects.

I test each NoScript build for end-of-browser-life leaks on latest Minefield trunk builds.
The "New Leak/Reclaimed Leak" routine you can see when NoScript is active is due to NoScript sometimes keeping references to windows or docshells some milliseconds longer than its natural lifecycle for various reasons (e.g. tracking networking/DOM relationships).
This obviously can't lead to long-lived (i.e. for seconds) leaks, even though the Leak monitor will fail to notice the reference has gone away until its next check, and therefore you'll have the "illusion" of a leak.

Though not entirely connected ,I checked the process explorer and it showed a whopping 240 mb against the usual 90 mb previously.FF 3.5.1

(There is some strange oddity with FF 3.5.x. Don't really use it, so haven't put my finger on it yet. But something like on a restart, perhaps after Addon change, sometimes it will use LOTS of Mem Usage? Or maybe that it uses a lot for some odd reason when shutting down, or maybe it is hanging a bit on shutdown, eating Mem?)

First let me say that I really enjoy NoScript, I would hate to live without it, but.....

I can confirm this leak, and we are not talking about a few 100 megabytes of RAM, but several gigabytes.
The issue as I experiences it, is as this guy has posted it here: http://forum.worldstart.com/showthread.php?t=139823

I have about 30 extensions installed along with flash and java, running Firefox on Linux (Fedora 11 RPM version).
When I start Firefox it takes ~130-140 MB RAM, open a few tabs (3) click here and there, so you send some requests, wait for page loads, read news, etc, normal browsing mode, and the ram climbs steadily to 400 MB, open another 10 tabs and it grows to 800-1000. Close the tabs and the RAM is not released.
Do some fast clinking on the same link to send.. Lets say 30 of the same requests to a server without having to wait for the page to reload each time, and slam 2.1 GB RAM has been eaten, and the browser gets slow and unresponsive, it can take minutes before I can use it again. Now when Firefox finally becomes responsive again, I then close all open tabs, but the RAM usage doesn't go down, not even 100 MB.

Doing the same with a Firefox profile that has no extensions or plugins, the RAM usage resides around 200 MB, so it is not Firefox it self.
I have a buddy that uses the same Firefox release as me, the only difference is that he has 2 extensions and 2 plugins installed and I have.. well around 30. His Firefox behaves the same way, so it is down to 1 of those 4 exts/plugins. To list them: Adblock+ - Java - Flash - NoScript. At first we thought it was Flash, as it is buggy as hell on Linux.x86_64, well it wasn't so I disabled Adblock+ cause it could have been one or more loaded filterlists, but same high RAM consumption occurs. Then I disabled NoScript and my RAM usage is is idle around 370 MB, no matter how many tabs I open/close and how many times I send the same request to a webserver.
My conclusion is simple, NoScript uses up to more than 50% of my RAM, and does not free it up until I restart Firefox, and I should mention that I can barely do more than a few clicks before the page is reloaded when NoScript is disabled, but when it is enabled the browser hangs and I can easily do 20-30 repeated requests.

Go ahead give it a try, log on to Facebook, play Mafia Wars, go to the hitlist and attack anyone or several at the same time (requires 30+ stamina of course).

System Info:
AMD Athlon64 X2 Dual Core Processor 4000+
4 GB RAM
Linux (Fedora 11)
Firefox 3.5.2-2.fc11.x86_64
NoScript 1.5.9

Jesper wrote:NoScript 1.5.9

And why are you exactly using such a relic of the past, answering to a two months old thread and referring to a 3 years old forum post?
Please install latest development build or latest stable at least, then we can talk about it again (hint: current NoScript versions are absolutely leak-free).

Jesper wrote:NoScript 1.5.9

You must mean 1.9.5, right? Please update to the most recent version, 1.9.8.72, available at http://noscript.net/getit#devel

I've been a NoScript user for over four years and I've never seen unreasonable memory requirement like you have. I don't have the stamina or interest to just flail around for hours like you seem to be suggesting, but I'm sure the NoScript developer would be interested in a well-defined, reproducible test case.

Since we're here ...
AMD Sempron 3000, 448 MB ram (512 - 64 used by onboard video)

Memory usages ...
Open FF35
Note SeaMonkey spooled partially out.
FF using an unusually high amount of memory, doing nothing but opening to home page.

Close FF
Note that SeaMonkey had spooled just about completely out.
(Making it a bear to load up again.)


Now I'm not saying this is in any way related to NoScript, but to me, something sure seems amiss - with FF, IMO.

I can open an instance of SeaMonkey 2, & another instance of SeaMonkey 1.1.18, & Eudora, & whatever, & having all this & everything else that I had open opened (except for FF) & none of this affects my first instance of SeaMonkey. It has not spooled out. All applications opening & loading & running as expected. Load FF & it acts like it owns me.


(Oh & just to point out, when FF loads, it actually loads in two pieces, both being named "firefox.exe". The first one starts, dies, & then the second takes over.)

Giorgio Maone wrote:

Jesper wrote:NoScript 1.5.9

And why are you exactly using such a relic of the past, answering to a two months old thread and referring to a 3 years old forum post?
Please install latest development build or latest stable at least, then we can talk about it again (hint: current NoScript versions are absolutely leak-free).

My bad, I meant to type 1.9.5 and I was referring to that topic cause the behavior is pretty fricken similiar .. I'll give the devel build a whirl and gets back with some results

OK, back with a first result, using the beta build.
NoScript definitely has improved on the RAM usage, as it is now free'd up when the tab is closed. And it is only going up to around 1-1.1 GB RAM. Thank you for alerting me to that a newer version than 1.9.5 was available, I didn't know due to Firefox obviously had not picked any newer versions up from addons.moz.org.

However with this build Firefox freezes for a longer period of time than 'normal' (with the older build and without NoScript enabled) when fast-clicking a link as described above in my original post. Of 40-50 clicks Firefox only catches between 5 and 16 before it freezes, where it with the older build was around 20-25 and without NoScript the page reloads and there is hardly any noticeable lock ups.


_
Jesper