The original firebug issue has been reported here, but the problem can be reported even *without* Firebug. http://code.google.com/p/fbug/issues/detail?id=3312 The test page is online here: http://getfirebug.com/tests/issues/3312/issue3312.html ... but you need to to install it (there are two files attached to the bug report) on a local server - the memory consumption is visible much better (at least on my machine, Firefox 4, Win Vista) --- Here is my scenario: 1) Start Firefox (memory consumption 30-35MB) 2) Load the page (still about 30-35MB) 3) Refresh the page (F5) about 20-30 times till the memory consumption goes to about 100MB 4) Wait, memory drops to about 60MB 5) Repeat #3 about 5-10 times 6) In the end, even after giving some time to GC for execution, the memory consumption can settle on 100MB (I am using win task-manager to watch how much memory is consumed by firefox process). --- I am seeing this *without* Firebug installed (it's getting worst with Firebug) on clean profile (no extensions). I have also used about:memory, but this page gives different numbers (smaller, but also growing). Related discussion: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/efd20422fb4e30fd?hl=en# I don't see any 'memory leak' related component and so, picking 'general', pleas adjust as appropriate. Honza

I can't reproduce this on Linux. Load of the browser: 71MB (RSS). Then I loaded that page and did 100 reloads, with some waiting in between. Memory rises occasionally up to 88 or so, but always returns to 83-84. Honza, on Windows, does memory usage for you stop at 100MB?

If its levelling out around 100MB then I believe this is fairly normal for a windows machine. If it ever gets past 200MB with no tabs open then its more likely a leak. The main reason I say this is that certain heaps like js/gc-heap levels out around 115MB during normal usage for me. These heaps also seem to level at different sizes on different OSs (no idea why).

(100MB - 35MB) = 65MB that's a leak IMO, even if it never gets another MB larger. 10 tabs an you are at 1GB. This test case generates a lot of message in the Error Console. I guess theses messages are queued up, perhaps with an upper bound.

(In reply to comment #1) > Honza, on Windows, does memory usage for you stop at 100MB? Yes, I am seeing the top at about 110 MB Honza

If memory usage stops at some point, then it almost certainly isn't a leak. A leak is where memory is taken up, but not released, so memory usage keeps going up and up (if you keep doing reloads to the page). There might still be a problem here that isn't a leak. The reason memory usage does go up to a certain level (here, 100-110MB) is because memory allocators allocate blocks of memory, and don't necessarily release them - they keep them alive so that future allocations will be faster. Now, if memory goes up to an unacceptable level, then there is a problem - we need to change the settings for how allocators work. But it is normal for memory usage to go up while using a browser, as long as it stabilizes at some point, and that point is not too high. 100-110MB is a reasonable amount of memory in this situation. What really surprises me is the 30MB at the beginning, which makes 100MB look like a lot (70MB difference). But I suspect that has something to do with how Windows reports memory usage, since on Linux I get 70MB on startup, which sounds more reasonable. And going from 70MB to 100MB is not that odd, 30MB is what I would expect to see given how our allocators work (but if it reached 200MB, I'd say something needs to be changed). So I am closing this bug as there isn't anything that needs fixing. Sometimes it is hard to tell apart memory leaks from normal memory usage, but the behavior in this particular situation looks normal.

(In reply to comment #5) > > There might still be a problem here that isn't a leak. The reason memory usage > does go up to a certain level (here, 100-110MB) is because memory allocators > allocate blocks of memory, and don't necessarily release them - they keep them > alive so that future allocations will be faster. A lot of that depends on what is being measured. The description didn't say, which makes it harder to diagnose. I can't wait to finish bug 633653 so all future reports can be made clearer.

Honza's report says: (I am using win task-manager to watch how much memory is consumed by firefox process). We have tried to use nsIMemoryReporterManager but we don't know what the results mean, if anything.

(In reply to comment #7) > > (I am using win task-manager to watch how much memory is consumed by > firefox process). Right... what metric is task manager reporting. According to http://en.wikipedia.org/wiki/Windows_Task_Manager it's working set size, which can be difficult to interpreter, but that could be wrong. > We have tried to use nsIMemoryReporterManager but we don't know what the > results mean, if anything. Bug 633653 will make things a lot clearer. It'll measure more things and also have better explanations of what each metric means.

I see the point why this bug has been closed. Just to note that this behavior (ie. memory usage does go up to a certain level) makes debugging memory leaks in an extensions (e.g. Firebug) even harder since any testing/test-case needs to make sure that the top has been reached before looking for any memory leaks impact. Honza