468003 - FF3 memory spikes upwards after about 4 minutes on about:blank

Status: RESOLVED DUPLICATE of bug 650649

(Toolkit :: Safe Browsing, defect)

Description

[Alex Vincent [:WeirdAl]]

Steps to reproduce:
(1) Visit about:blank in a fresh FF3 profile.
(2) Observe Firefox's memory consumption in the task manager for ten minutes.

FF3.0.4 starts at about 27MB, but then suddenly spike up to about 44MB after a few minutes. It seems to remain stable at 44MB. (Different runs ranging from 43,600KB to 44,476KB in my observation)

FF2.0.0.18 stock, initial load averages
21.5MB to 22.0MB per instance. Holding very steady at those levels.

Comment 1

[Sylvain Pasche]

I guess that could have something to do with safe browsing.  Can you reproduce if you set browser.safebrowsing.malware.enabled/browser.safebrowsing.enabled to false?

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

Testing this morning with 3.2a1pre on a 'virgin' profile.

I deleted the livemarks folder
Tools->options->Advanced->Updates : unchecked all the 'update' boxes
In about:config - changed browser.safebrowsing.malware.enabled to 'false'
Closed Minefiled
Set Tools->Options->Main : When the browser starts to 'about:blank'
closed the two default tabs you get when opening the browser on a fresh profile

I removed urlclassifier.sqlite file

Restarted Minefield and watched the taskmanager for 15 mins, there was a slight download of some 650k to urlclassifier after about 2 mins of starting the browser, but no more followed and the memory stayed steady.

Testing before tweaking the malware pref I did see incremental increases in memory use, and watching with 'Explorer' I saw the urlclassifier journal downloading the malware data.  The file itself remained at 0kb until I closed the browser, then wrote the download data to the file.  This leads me to believe that the malware-data downloads are loading into memory during the download, which is a slow process in small data-chunks.  

Copying over a 'mature' urlclassifier.sqlite file from my working profile resulted in no increase of memory - so it appears what your seeing is indeed related to the malware-data push, and should be of no concern I would think.


Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20081205 Minefield/3.2a1pre Firefox/3.0.4 ID:20081205041334

Comment 3

[Alex Vincent [:WeirdAl]]

Unfortunately, it is a concern for us, since we run not one, but several FF instances at once.  Every MB has a cost for us.

Let me do some thinking on this - safebrowsing is obstensibly a good idea, but it may be impractical for us at Skyfire to do it inside the Firefox browser.  We may want to offload it to some external point.

Comment 4

[Alex Vincent [:WeirdAl]]

Confirmed, when the safebrowsing preference is set to false, FF consumes on average 30.5 MB of memory, give or take about 400KB.

So why does the phishing protection code eat 13MB+ of RAM?

Comment 5

[Alex Vincent [:WeirdAl]]

Incidentally, I observed the excess memory consumption with FF3.1b2 and with FF3.0.4.  Requesting blocking-firefox3.1 to look into it.

Comment 6

[Daniel Veditz [:dveditz] back January 5, 2026]

It's not a "mlk" if the memory is being used and freed correctly at the end. Is it really leaking? "footprint" seems a better tag for this.

Comment 7

[Alex Vincent [:WeirdAl]]

I have no idea if it's a leak or not - and you're probably right, footprint sounds better.

Comment 8

[Mike Connor [:mconnor]]

So, this is the first-time overhead, but shouldn't always be this high on subsequent loads.  There's a lot of expected overhead in setting up the initial safebrowsing DB over the network.  The only way to fix this would be to do the initial setup much slower, and that's a tradeoff we decided to make in the interest of getting maximum protection on first run.

Comment 9

[Dave Camp (:dcamp)]

Another option would be to always throw away the sqlite cache after updates.  We do this on linux where we let the cache grow bigger.