464648 - FireFox 3.0 + Kaspersky 2009 causes high firefox memory usage

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Danial Horton]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre

Firefox 3.0 is only releasing 25-50% of memory used by Tabs on close. The issue is aggravated by Image albums leading me to believe that the Memory held by Images is not being released, Even worse is that BFCache itself may be broken.

This was not an issue with Firefox 3.0 beta 3, but has been since Firefox 3.0 final and up in the latest nightly

The results have been tested across a typically used and abused profile, and 3 fresh profiles, all of which have had the bfcache disabled by setting browser.sessionhistory.max_total_viewers to 0 to ensure that the memory isn't in use by the bfcache. exact results were replicated by disabling cache to memory via browser.cache.memory.enable to false.

People who open 1 or 2 tabs, with a few sites are not going to validate this problem, however those who open and close tabs, in excess of having opened and closed atleast 100 tabs in a single session will experience this.

The sites i've been visiting have not changed at all, I've noticed up to 800MB's memory usage, with the pagefile at 1400MB's, while in comparison to Firefox 2 with the same usage memory usage was 450/450.

Closing all Tabs does not show any change in memory usage in Firefox 3, while closing all tabs in Firefox 2 will have memory drop back to where it would be at a fresh start of firefox (45-125MB).

As flashblock is used, theres no chance it is Flash or shockwave, and no Java applets have been loaded during the session. In the fresh profile, the java flash and shockwave plugins are disabled to prevent them effecting memory usage.

Reproducible: Always

Steps to Reproduce:
1. New profile, start firefox
2. About:config, set browser.sessionhistory.max_total_viewers 0 and browser.cache.memory.enable false
3. Browse various image intensive sites in multiple tabs such as photobucket, or flikr.
4. Close the tabs and note the memory usage has only dropped by 25%.
5. Open the same sites(same pages is best) and note that even though the memory hasn't been released since the tabs closed, more memory is used to show the same site again.
Actual Results:  
Memory is not freed as tabs are closed, leading to large amounts of memory used during the browsing session. Loading the same page into memory takes even more memory even though the data should still load from memory.

Expected Results:  
Memory used by a tab is completely released unless used by other tabs, and if data is already cached, firefox should not use more memory to load the same stuff.

Since memory usage is not changing regardless of the setting of BFCache, It might be caused by a failre in BFCache to work.

Similar high memory usage was seen on firefox 2 until BFCache was disabled, however toggling the BFCache setting has not changed memory usage in Firefox 3, since Firefox 3.0 beta 3

Comment 1

[Carsten Book [:Tomcat]]

i will look into this with Memory Leak Test Builds

Comment 2

[Danial Horton]

I've Isolated the Cause, though i don't know how it effects it, to the Kaspersky 2009 NDIS filter driver.

Removal of the filter restores firefox to working order.

posted about it here http://forum.kaspersky.com/index.php?showtopic=91814

Comment 3

[(not currently active) Ted Mielczarek]

Would be nice to figure out if this is preventable on our end, or if it's just a bug in Kaspersky and nothing we can do about it. (In which case, it'd be nice to make contact there and see if they can fix it on their end.)

Comment 4

[Nochum Sossonko [:Natch]]

Note see bug 454693, not sure if it's valid anymore as I re-installed the older version. I was hitting assertions all over the place.

Comment 5

[Danial Horton]

Installed the latest release version, and not even removing the NDIS filter works now.

Not the only kaspersky user experiencing it either, this should be a priority between both Fx devs and Kaspersky devs since it is one of the best rated AV firms.

Comment 6

[(not currently active) Ted Mielczarek]

There isn't much Firefox developers can do. Kaspersky is not an open source product. The Kaspersky developers are in a better position here, since they can examine our code as well as theirs.

Comment 7

[Danial Horton]

I realise this, however I'm posting this so someone who has a bit more experience then me can approach them with the required logging information.

Comment 8

[Danial Horton]

I'm not in a position to approach Kaspersky on this issue (not able to compile leak test or debug builds) so can someone who can gather any necessary information and post it @ http://forum.kaspersky.com/index.php?showtopic=91814&st=0&gopid=830926&#entry830926

Comment 9

[Danial Horton]

Changing Platform to All OS, as theres no overall Windows category, and it effects XP, Vista, Windows 7 in my own experience so far.

Comment 10

[(not currently active) Ted Mielczarek]

Still, please leave it at Windows XP, since it doesn't affect Mac or Linux.

Comment 11

[Danial Horton]

I've done some further tracking of the issue, and have now pinpointed the memory issue to the mozilla 2 and mozilla 3 virtual keyboard dll's installed with kaspersky 2009.


Heh, they've had issues with this damn virtual keyboard from the start.

Comment 12

[sdmarathe]

Disable Close Tab settings - Fx keeps even the closed tab in mem and does not return the memory fully. set browser.sessionstore.max_tabs_undo to zero - this will prevent memory leak from trough to trough..

Comment 13

[Danial Horton]

Unrelated to this issue,but thanks for trying anyway.

Comment 14

[[:Cww]]

Haven't seen specific reports that can be pinned to this

Comment 15

[Wayne Mery (:wsmwk)]

Danial, is this still seen with current versions?

Comment 16

[Danial Horton]

I dropped Kaspersky unfortunately, so i don't know,

works fine with Security essentials however.

Comment 17

[Tyler Downer [He/Him]]

We'll go ahead and close as WFM unless someone else can reproduce.