[RESOLVED] Nightly 6.0a1 + NS 2.1.0.3: memory leak

[_nil]

Nightly 6.0a1 (2011-05-12)
NoScript 2.1.0.3
No other addons or plugins enabled.

Javascript heap memory is leaked after visiting hxp://ro.me, when scripting is allowed there. Closing the tab or the window, or manually invoking GC/CC, will not free the leaked memory. Without NoScript, this appears not to occur (if it does, it's much less obvious.)

[Giorgio Maone]

Is there a Firefox regression window (did it start with a specific nightly build)?
If so, please file a bug report at https://bugzilla.mozilla.org

[GµårÐïåñ]

I am running the latest build of nightly and not encountering this. Do you have other addons installed? That might be your problem because with my copy and NoScript, RequestPolicy, Ghostery, and Adblock Plus, I am not encountering what you are saying. This suggests you have another addon or configuration that is causing it, so take a look there.

[therube]

FF4, it ate up a chunk of memory (1.5 GB) & CPU (25%, 1 of 4 cores).
Closing the tab worked, but mem/cpu have remained & now I can't regain focus of FF.

Let me kill, disable NoScript & see ...

Ah, what'd'ya know, the numbers finally subsided (& I mean after minutes).
Well CPU has dropped to nil, though mem has only dropped to 1.45 GB.

And more interesting. "Closing" FF, cpu is back up to 25%, mem is at 1.36 GB.
The "Window" is gone, but the process has remained.
(At first I thought it was only going to take some time before it released from memory, but that does not look to be the case.)


NoScript disabled.

1.44 GB, 25%.

Close tab & same sort of response. mem/cpu remain high 25/1.43 & unable to regain focus.
Lets see if I can get focus in a few minutes ...

OK focus is back (took less time then before), CPU has dropped to nil & mem is now at 266 MB (around where it started to begin with).

And closing FF, it drops from memory almost immediately.


So I'm seeing a decided difference with having NoScript installed or not.


Without NoScript it looks like this (View Image to see full size if need be):

[Giorgio Maone]

Investigating, thanks.

[therube]

(I know no mention, but 2.1.0.4rc9 may now be causing crash on http://www.ro.me/ on closing tab?)
Worthless report, https://crash-stats.mozilla.com/report/ ... 0c02110514.

[dhouwn]

AFAIK the latest nightlies have or will soon have many about:memory improvements (haven't looked into them yet), maybe this will prove helpful.

[Giorgio Maone]

Please check latest development build (rc10), thanks.

[therube]

Looks good. Took a bit of time for the memory/cpu to drop after closing the tab, but it did.

[therube]

Though ... in SeaMonkey 2.1, I am not getting CPU usage to subside.
Quitting did close the windows, did release seamonkey.exe from memory (i.e. it did not hang in memory on Quit).

[Giorgio Maone]

Though ... in SeaMonkey 2.1, I am not getting CPU usage to subside.

It may depend on differences in hardware acceleration between SM and Fx (not sure if they exist, but it's possible as they may have different compilation options).
Does disabling NS actually help on SM?

[_nil]

Latest development NoScript, same Nightly.

After waiting for the film to finish loading and closing the tab, the cycle collector strains for awhile (~25s, for three collections, on ~800mb of heap), but ends up successfully freeing the allocated memory. WFM; thanks a lot!

[therube]

Does disabling NS actually help on SM?

No, in -safe-mode I crash during playback .

[therube]

Closing down other instances of SeaMonkey/FF (i.e. freeing up much memory) I playback successfully (in -safe-mode).
Closing the tab, & memory looks to be holding steady - high, 1.38 GB, but I'll give it some time & see if it drops ...

< stand by, will update in a bit ... >

Many minutes later, & memory usage has not dropped at all, so not a NoScript issue.

Quitting did (eventually) release seamonkey.exe from memory.

[therube]

FF4 -safe-mode did also crash on me, so maybe ro.me is just not going to work (reliably) in Gecko 2.0.1.
(Worthless report, https://crash-stats.mozilla.com/report/ ... 99f2110515.)

(Trying again ...)

FF4 -safe-mode crashed again.

So one for one in SeaMonkey 2.1, 0 for two in FF 4.0.1.