Closed Bug 131456 Opened 23 years ago Closed 18 years ago

Memory use does not go down after closing tabs (resources not released)

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fleona, Assigned: dbaron)

References

(
URL
)

Details

(Whiteboard: mlk?)

Attachments

(10 files, 1 obsolete file)

screenshot 1 of 2 (task manager) showing the problem
257.58 KB, image/jpeg
Details
screenshot 2 of 2 (about:cache) showing the problem
128.31 KB, image/jpeg
Details
Screenshot for task manager and about:cache with no tabs
88.01 KB, image/png
Details
Firefox uses 400MB+ RAM memory.
13.99 KB, image/png
Details
port a bunch of firefox leak fixes over
4.50 KB, patch
bzbarsky
: superreview+
Details | Diff | Splinter Review
parallel changes that aren't in Firefox yet
2.36 KB, patch
Details | Diff | Splinter Review
Memory consumption with 1 tab
26.52 KB, image/png
Details
Firefox using lots of memory after tab closed
126.58 KB, image/jpeg
Details
Browser Mem Buster Test testcase popup file
321 bytes, text/html
Details
Browser Mem Buster Test testcase
5.83 KB, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002031115 opening lots of tabs and then closing then do not free memory Reproducible: Always Steps to Reproduce: 1.Choose a page with bloat that you hate. Icq works fine. Any page works, really 2.Open any link in them (i chose the blue icq logo) 19 times in tabs 3.Watch memory use Actual Results: When first loaded: -Mozilla eats 8% of my 256mb After the first icq webpage is opened -Mozilla eats 9.6% After the other 19 tabs are opened: -Mozilla eats 17.4% After closing those 19 tabs: -Mozilla still eats 17.4% After loading bugzilla to file this bug: -Mozilla eats 21.5%! Expected Results: I really dont know what it's supposed to happen. I know mozilla should keep something in the memory cache , but this is over the line
Keywords: perf
i'm experiencing a similar problem on Mac OS X, actually. opening several individual browser windows leaves VSIZE at upwards of 225MB, even after all windows are then closed.
I can confirm that this also occurs on Windows builds (RC1/2). I suggest the platform is changed to All. Cc'ing myself because it's a pain when ChatZilla's causing Moz to use ~50MB of RAM and never lets the OS reclaim it.
Platform: PC OS: Windows 2000 SP2 Build 2195 BuildID: 20020617 I opened www.icq.com, picked a link at random, and opened that link in a new tab a total of twenty-five times. At the end of this process, the Task Manager showed I was using 156408K out of 310828K total RAM available. After this, I closed each tab. Memory usage dropped each time I closed a tab. Additionally, it seems that BuildID 2002031115 is too old a build to report bugs against now. I am not sure about Linux or MacOS but it appears that on Windows this problem may have been fixed already. Could you please download a recent nightly build from <ftp://ftp.mozilla.org/pub/mozilla/nightly/>, and then let us know if you still see this problem? Thanks, Brian Weir
Let's try XPApps for this one.
Assignee: asa → sgehani
Component: Browser-General → XP Apps
QA Contact: doron → paw
Mozilla Build 2002081119, W2k I use mozilla now to acess our web-based CMS at work. Although basically it works great memory usage is an issue. I have mozilla running all day, working with the CMS interface which means lot of javascript functionality, lots of popup windows, lots of page reloads etc. Although there are only a few windows open simultaneously memory usage grows over the day and never comes down. Currently I have only this window open, typing in bugzilla and task manager shows mem usage: 228MB, VM Size: 265MB for mozilla.exe
Reporter or anyone else able to reproduce behavior: Is 'Quick Launch' on? I have a similar bug (#166979) that could be caused because of Quick Launch. Thanks.
It seems I'm seeing either this bug or something very similar. (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20020929, Win NT4.0) But first of all: the summary says "Memory use does not go down after closing *windows*", but in the description, the reporter is talking about *tabs*. Which of the two is it for the people who commented so far? From now on, I'll be talking about *tabs*. I'm seeing a memory leak problem when opening multiple tabs - the manifestation seems to depend on what's being displayed in the tabs. o If I open multiple tabs, and in each of them display a local .jpg using a "file://"-type URL, total used memory (according to the graph in the Task Manager) increases as expected. However, if I then close the tabs one after the other, the graph doesn't go down again. Doing this several times, I can quickly exhaust all available virtual memory. o The same happens if I visit a remote site that directly links to .jpg files o However, if I e.g. go to http://www.formula1.com/races/racenews02/usa/pics.html , and open several pictures in tabs, I won't leak any memory: after I closed the last tab, I'll see the same amount of used memory as before opening the first tab. I tried several other locations presenting images ( http://www.anseladams.com , http://www.photographie.de/galerie/galerie_start.cfm , ...), and all of them show the same behavior: if the links opened point to a HTML page (which then contains the image), I will reclaim the memory after closing the tab, but if the link directly points to a .jpg, the memory will be lost. o Interesting in this respect is http://images.google.com : Go there, search e.g. for 'dogs' and open some of the results in new tabs. Each of the tabs will contain an HTML page with a medium sized version of the image, which is a link to the large version of the image. If I simply close the tabs one by one, all memory will be reclaimed. However, if I go through the tabs and click the medium sized images (so that each tab now contains the .jpg), the memory will be lost upon closing the tabs. to the original memory consumption after closing This behavior has appeared somtime after 1.0 - unfortunately, I can't be more precise, since I noticed it on a machine which I update to a new nightly only occasionally. But I'm very sure that the problem has either newly appeared or has become much more severe, since I almost exclusively use tabs, and often open images in new tabs. I would have noticed the memory problem, had it been present in my previous installation of Mozilla. Regarding comment #6: I don't use quick-lauch, and I have never activated it. Greetings, -Chris
*** Bug 149607 has been marked as a duplicate of this bug. ***
The problem does not seem to depend on the setting of any of the 'cache' options: if I either set the disk and mem-cache size to 0 in Advanced | Cache, of if I disable disk and mem-cache altogether in Debug | Networking, the problem still persists. @ owner or submitter: I'd suggest changing the keywords to include 'footprint' and the OS to 'All' (I can reproduce the problem on Linux and NT4.0). Also, I'd suggest changeing the summary to reflect that the problem affects both tabs and windows. I don't have the privs to change any of these fields. -Chris
OS->all per comment 9. I'm not sure 'footprint' is the right keyword; mlk seems more appropriate (but we need a purity or equivelant report for that, no?)
OS: Linux → All
Whiteboard: mlk?
Changing summary as per comment 7. QAwanted to determine whether this is a memory leak.
URL: http://web.icq.com → http://web.icq.com/
Keywords: qawanted
Summary: Memory use does not go down after closing windows → Memory use does not go down after closing tabs
*** Bug 184622 has been marked as a duplicate of this bug. ***
For the sake of information flow: there has been a checkin for bug 179498 that fixes my observation of memory 'leakage' when loading images. After updating to Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021214, I can no longer reproduce my observation from comment #7. Therefore, for me this is fixed. However, the whole problem seemed a bit muddled, with different people referring to different scenarios, so everyone affected by this bug might want to retest, in case there are other aspects to this bug that might warrant keeping it open.
For me, this bug still happends. It seems that the problem is that Mozilla never release memory, or not so agresively. After 1 hour of browsing, I have to quit Mozilla because he is using 100MB of swap file and 80MB of RAM.(Sometime it is more memory usage) I have no test case, but if you browse many sites during a long period of time and then close all windows and let only one "about:blank" window open, Mozilla does not release all the memory. Tested in Mozilla 1.3b Build ID 2003021008
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030303 Confirming comment #14 with a newer build
*** Bug 197356 has been marked as a duplicate of this bug. ***
Severity: critical → major
Keywords: perf
Hardware: PC → All
Flags: blocking1.4a?
Keywords: qawanted → nsbeta1
Andrew, if no patch has been posted, it is unlikely a bug will be accepted in any next alpha... First find a patch (or make one) and then ask for blocking. I've made this mistake myself a couple times, so let's learn from each other.
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Flags: blocking1.4a? → blocking1.4a-
This has definitely regressed after 1.3. Now Mozilla again exhibits exactly the same behavior that it used to have on 1.2alpha-beta (before the fix to 179498). After browsing with tabs for about 15 minutes (While all the time closing and opening new tabs), Mozilla memory footprint goes up drastically (to 60-80MB) and then the screen stops refreshing. Closing screens/tabs at this point does not help, and Mozilla has to be restarted. This is more noticeable when browsing for pictures (And probably is still related to 179498).
As per comment 14, if you work with frames and keep refreshing one of the frames, Moizlla will eventually crash completely. I have only seen this happen on dynamic pages (PHP). When designing websites, I constatly make small changes and upload them to server to preview what they are going to look like. I do this through refreshing only the frame that I just uploaded, not the whole frameset. I've seen Mozilla (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312) crash 4 times this way. The website I'm talking about is www.pscbath.com/new. Then, go to "Contact Us" and refresh the frame about 20-30 times. I'm not sure if this relates to this post, but it could be caused by the same bug / memory leak.
Re: comment 19. If that is true, then open a new bug. Don't comment in this one.
Just for information. On Linux i686, glibc 2.3.2 moz 1.3.1 muild 20030425 I can see the same behaviour. During developement one PHP ran out and generated 100MB of code. Mozilla mem usage is now 131MB about 20 hours already (all tabs closed or reloaded to something else). Is not there way to dump memory blocks with some debug info (owner) ?
*** Bug 159572 has been marked as a duplicate of this bug. ***
*** Bug 212377 has been marked as a duplicate of this bug. ***
I can confirm this on Windows XP with all of the recent Firebird nightlies (up to and including 08/08/2003). Another thing I've noticed, which may or may not be related, is that often going to about:cache will show that my memory cache is larger than it's maximum size. Perhaps a component of this bug is causing the memory cache to grow when memory is not released?
Some posted that it is not affected by the current cache size...have you tried this with your cache set to automatic? browser.cache.memory.capacity = -1 I can confirm this behavior when I manually set any value for the memory cache, but if I leave the memory cache on automatic it seems to release memory properly when tabs are closed. Anyone confirm?
I don't have much to add to this, but I was wondering if it was related to Mozilla's capability to restore closed tabs (I have that bound to a double-click on tab bar personally)? I had assumed it just kept track of URLs, but I guess that would be no good for a lot of information needed to get the same page back. Maybe it caches them? If so, a release mechanism is needed, or a limit on cached pages.
What is the "restore closed tabs" feature mentioned in comment 27? I can't seem to find it anywhere in the menus, etc. (using build 2003092704).
Well, that's just it. The restoring closed tabs is part of several mozdev projects. The thing is, I have no idea if they are implementing it separately, or calling undocumented underlying functionality.
I can confirm this also happens with Firebird. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Task Mangaer says it's using approx 65,688K while browsing Bugzilla with just this one tab open.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031107 Firebird/0.7+ I had 2 tabs open and firebird was using more than 100mb :| looks like a major memory leak, hope this will be fixed soon
Re: comment 26. No, on recent Firebird builds, setting browser.cache.memory.capacity to -1 doesn't help. Loaded 50+ tabs with the same CNN page and closed all but one. Memory usage still ~70MB.
Blocks: majorbugs
Isn't this really a meta bug? There must be a number of other bugs that cause this problem.
Flags: blocking1.8a?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Regually get memory expanding stupidly about:cache shows Memory cache device Number of entries: 378 Maximum storage size: 21504 k Storage in use: 11445 k Inactive Storage: 11071 k Disk cache device Number of entries: 309 Maximum storage size: 50000 k Storage in use: 1466 k Cache Directory: H:\APPS\Profiles\Kev07\yui6pc7t.slt\Cache Task Manager shows 54MB, only been opened for 5 minutes (of which two tabs have been closed) - it has just crashed on me twice in a row - both on VB3 based forums (it's been doing it since any went VB3), less than five minutes each time - in once case only opening two tabs/. Launch Memory usage went from 25MB to some 200MB at approxomatly 1MB a second before it fell over. System is Win XP SP1, UK Regional Settings, latest Java VM (Sun) and Flash Player.... CPU usage normally very high (80 - 99%) before it falls over too.
Flags: blocking1.7?
This is the most critical bug in Firebird for me. Just look at my about:cache: Memory cache device Number of entries: 1180 Maximum storage size: 12288 k Storage in use: 62892 k Inactive Storage: 0 k That ain't right, surely?? OK yes I do have a very large number of tabs open but as widely reported mem use does not go down for me when I close tabs, which results in nightmare-ish memory usage (and massive system-wide performance degradation) after time. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Flags: blocking1.8a? → blocking1.8a-
Flags: blocking1.7? → blocking1.7-
*** Bug 249320 has been marked as a duplicate of this bug. ***
Whats the point of even marking it a duplicate bug - you guys haven't even fixed it in TWO YEARS. When another software vendor comes out with a tabbed browser that doesnt swallow memory like this, you know what people are going to switch to - thats the kind of browser I am now looking for. PLEASE FIX THIS ALREADY - ITS ABOUT TIME - INSTEAD OF SPENDING THE TIME JUST MARKING DUPLICATES OF THIS BUG OVER THE YEARS.
This is a very important bug which should be fixed immediately. We can see it on the 111 votes. Samir seems to be not interested in this bug. Anyway, I reassign this bug to the default owner with the hope to get more and better audience. Asking for blocking Aviary1.0RC1. I have used this flag because development is quiet faster in that tree and end users are more affected by this bug. After it is fixed it could be backported to SeaMonkey.
Assignee: samir_bugzilla → jag
Flags: blocking-aviary1.0RC1?
Sorry for the bugspam, but re Comment 37 & Comment 38: We were discussing this in the #firefox channel and I think this quote sums it up best: "If it was possible, it'd have been fixed, it ain't a nice one, and certainly not one you can 'just fix'." I think the dev/drivers/etc know what they're doing, let them do their work, if you feel this is such a grave bug, submit a testcase/patch/etc to help.
(In reply to comment #29) > Well, that's just it. The restoring closed tabs is part of several mozdev projects. > The thing is, I have no idea if they are implementing it separately, or calling > undocumented underlying functionality. In case someone finds usefull to look a their code, here's a list of tab-related extensions: http://extensionroom.mozdev.org/list.php/Mozilla/tabwin
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1-
Concerns have been raised in bug 172962 that with the new integrated tab controls drastically increasing the number of tabs that may be opened during a given Firefox session, the problems within this bug may be exacerbated. Will this bug become a larger problem if more tabs are being opened during a given session?
Re comment 41, yes if people open more tabs, this will become more of an issue. It's reasonably linear in number of simultaneous open tabs. It's time consuming to gather actual statistics, but my gut feeling is that it's less important but still a factor if a smaller number of tabs are repeatedly opened and closed.
Opera has a feature that is not only brilliant and useful, but also is a work around for this issue. It saves your tabs state in real time, so if there is a crash or if you decide to close and re-open your browser, you have the prompted option to be able to restart exactly where you left off - the current page contents on all the tabs are even cached. AND guess what - simply closing and reopening the browser in this fashion FREES UP ALL that memory that you lost - hence an easy work around with no penalty. Opera also has many other superior features and I have since moved on from Mozilla and firefox. All you need to do is customize the default key maps a bit (using the front end - very easy) so that everything is to your liking - its very customizable. To save a group of tabs you make a new folder in bookmarks and add all.
(In reply to comment #43) > Opera has a feature that is not only brilliant and useful, but also is a work > around for this issue. It saves your tabs state in real time, so if there is a > crash or if you decide to close and re-open your browser, you have the prompted > option to be able to restart exactly where you left off - the current page > contents on all the tabs are even cached. I really don't like that feature at all, personally (and it wouldn't work for posted data, etc... really, who needs to keep several windows/tabs open all the time?) but it would not by any means solve this bug - at least imho. If the Opera developers told you, "umm, sorry, there's a bug in Opera so you're going to have to like, erm, close your browser and open it again after say... I dunno, 2 hours of use? Yeah, sorry about that..." would you be happy? Not a solution in my mind.... but, it may be a while before one is found, I fear :/. -[Unknown]
Its so unfortunate when people feel that just because they don't work in a certain way that others shouldn't either. I find it extremely useful to have a set of tabs open. Usually it acts like a notebook of all the outstanding things I am currently dealig with. I am usually working on multiple things and leave up stories to read later, deals I am considering, etc etc. And its so convenient to close this "notebook" and reopen it all where it was. Opera didn't suggest this is a solution. Nor did I - I said its a kind of acts like a temporary work around. It also seems that all Non-IE browser that speak to the windows API have this problem with memory. BUT this work around is very simple in the mean time, and is a life saver also if your machine crashes freezes or doesnt come out of sleep mode or whatever other circumstances.
(In reply to comment #45) IMHO this discussion doesn't help us solve the problem. This bug is about memory-use. You are talking about Tab-features/enhancements. What you're looking for might be here: http://piro.sakura.ne.jp/xul/_tabextensions.html.en
Lets see... the town well is not producing enough water. We are all rationing the water and everyone is getting thirsty all the time. We are all frustrated and the situation has been going on for 3 years. But wait - "hey guys, in this cave there is a secret entrance, and inside I found an underground fresh water stream. It takes 10 more seconds to get water there than from the town well, but there is an endless supply - enough for everyone!" Townsperson (or well fixer (pun intended)) - "IMHO, I dont think that's relavant - we are trying to fix the town well and you are talking about secret entrances and caves." IMHO - I don't think you CLEARLY read both my posts - with the work around. Yes certainly go fix the town well (ie (<-wtf:-) - memory loss), but in the meantime let all the frustrated and thirsty people be aware of where to get water in the meantime! This bug is a duplicate of other bugs reported over 3 years ago. The Mozilla team unfortunately deserves their just desserts if they have left such an important bug as this memory loss go unsolved for 3 years, and people start to turn to other means or Opera for an easy work around (if that's in fact what you are really worried about).
(Sorry for bugspam) Re: Comment #47 Read the previous comment (#46), use TBE if you want to save and reload tabs as a 'workaround'. It has the ability to save and load tab sessions. So please go use the secret entrance (TBE) and leave everybody alone while the carpenters/stone masons/etc (Mozilla Developers) work on making the well bigger and larger so everybody can have fresh water (getting rid of the memory leak).
*** Bug 257896 has been marked as a duplicate of this bug. ***
*** Bug 257896 has been marked as a duplicate of this bug. ***
Summary: Memory use does not go down after closing tabs → Memory use does not go down after closing tabs (resources not released)
(In reply to comment #0) > opening lots of tabs and then closing then do not free memory It seems to be not just tab related, even opening new windows and closing them doesn't free *most memory* I just tried it with a large site home page; opened FF with a blank home page, and its usage of memory was initially around 8 MiB, then I opened a second window to that site, that raised memory usage to a peak over 29 MiB, then stabilizing around 28 MiB. At this point I closed the new window, and it shrunk just to 27 MiB. From many other tests I had, with different applications running concurrently, became clear to me that only Firefox and Thunderbird do show such a behaviour -- never releasing most of the memory they allocate, even if the system is running low of RAM and needs to swap to disk. I rate it as a very annoying behaviour, since it can force me closing Firefox and/or Thunderbird, before I run any heavy application legitimated to use a lot of memory: that amount of memory could be unavailable, just because is wasted elsewhere. It's been very unpleasant discovering it's a well known bug since two years.
It's interesting that no-one pointed this out yet, so I will: it's rare that a [s]brk'ing memory allocator (as used by most applications on most systems, including Mozilla's main platforms) EVER gives a large proportion of an application's memory back to the system for other applications to use. Some combinations of app allocation patterns and allocators do render this possible to a degree, but a cross-platform app is going to find it almost impossible to hit those patterns correctly across platform allocation implementations. The upshot of this is that once an application's memory usage hits a peak, only a proportion of this memory will usually be returned to the system even if the application correctly frees it again, until the application exits (though this memory is preferentially given back to the application when it allocates more memory again, so it is neither 'lost' nor 'leaked' memory).
(In reply to comment #52) > It's interesting that no-one pointed this out yet, so I will: it's rare that a > [s]brk'ing memory allocator (as used by most applications on most systems, > including Mozilla's main platforms) EVER gives a large proportion of an > application's memory back to the system for other applications to use. I think that should be an OS responsibility, that kind of management. With the applications I run, on daily basis, I find they give back what's not anymore needed -- with no need on exiting completely from them. > Some combinations of app allocation patterns and allocators do render this > possible to a degree, but a cross-platform app is going to find it almost > impossible to hit those patterns correctly across platform allocation > implementations. I guess it's the case I tested with gimp, where I started the application and showed a 15 MiB allocation, then I opened some large bitmaps to totalize 87 MiB; after I closed them it returned to just 26, and not again to 15 -- not a perfect world, but I guess it can be acceptable(?). Things showed to be different, in numbers, with Firefox: opening pages for 90 MiB and closing them, released at most 4-5 MiB. > The upshot of this is that once an application's memory usage hits a peak, only > a proportion of this memory will usually be returned to the system even if the > application correctly frees it again, until the application exits (though this > memory is preferentially given back to the application when it allocates more > memory again, so it is neither 'lost' nor 'leaked' memory). I do agree on 'preferentially'; what I think to be 'unacceptable' is that memory (with FF) isn't released back to OS, that can decide what to do with it. I didn't mention 'leaks', since I'm quite sure it's not a leak, I saw how it was re-used (or so I hope). Just wanted to point the annoying waste of RAM -- or the swap space too, when running low of RAM. Maybe could be seen as a marginal usability issue as well: do all the users know that after a long browsing session (with all the browser tab/windows closed, but one), they could see system slowdown or the inhability to edit/view a large document of different kind? I forgot to add in the previous note that I conducted the tests on Firefox 1.0PR / Windows XP pro, SP2, 512 MiB RAM, running Process Explorer 8.52 from Sysinternals (http://www.sysinternals.com), that gives some more information than the built-in Task Manager.
(In reply to comment #52) > [s]brk'ing memory allocator (as used by most applications on most systems, > including Mozilla's main platforms) EVER gives a large proportion of an > application's memory back to the system for other applications to use. In case you're speaking virtual memory, you are right. But virtual memory (address space) is 'free' -- it doesn't cost much to have much of it allocated all the time. What matters is committed memory usage and every test should take it into account. Every application should always return all committed memory it allocated and there are no operating systems that make it impossible. Application may cache some data and not always return all the committed memory, but in such case they should reach "stable memory allocation state". There's no excuse to getting more and more memory allocated (committed).
(In reply to comment #54) > In case you're speaking virtual memory, you are right. But virtual memory > (address space) is 'free' -- it doesn't cost much to have much of it > allocated all the time. Only true for untouched pages -- unless the libc gives hints to the OS, pages which the application has allocated *and* touched are no longer virtual even after free()ing. Some heap implementations do sbrk() the data area back down if there are a run of free pages at the top of the heap, which will truly 'free' those pages, but otherwise they have to resort to non-sbrk allocation methods (for example mmap'd hunks and pools) -- these are a reasonable way to stand a better/good chance of properly freeing entirely- free()'d dirty pages, but again unpredictable across platforms to specifically code for, and for performance reasons these usually only kick on on larger hunk sizes. > What matters is committed memory usage and every test should take it > into account. Every application should always return all committed > memory it allocated and there are no operating systems that make it > impossible. Rarely impossible, but for performance reasons rarely desirable and for historical reasons rarely practical. Libc's tend to be more pragmatic than aggressive (a page per allocation, for example, would be outrageous). > Application may cache some data and not always return > all the committed memory, but in such case they should reach "stable > memory allocation state". There's no excuse to getting more and more > memory allocated (committed). Indeed, that would be a genuine leak or a really unfortunate allocation pattern....
Flags: blocking-aviary1.0+
Flags: blocking-aviary1.0+
Please don't set blocking flags on bugs that don't have patches attached. Bring it up often on mozillazine, test each new release, but setting a blocking flag for a bug with no patch will only get you on people's shit lists. Best case is to find an exact test case that causes the problem to be reproducable every time.
Dudes, I see all this fuss about this bug, and I agree with it, since I experience it. But will actually someone try to fix this bug. Yesterday FF 1.0 was released, and this bugg is lingering around! Which release will have this bug fixed FF 3.3a?
(In reply to comment #57) > Dudes, I see all this fuss about this bug, and I agree with it, since I > experience it. But will actually someone try to fix this bug. Yesterday FF 1.0 > was released, and this bugg is lingering around! > Which release will have this bug fixed FF 3.3a? I'm afraid that comments like that aren't very helpful. This isn't killing anyone, and I've browsed with large numbers of tabs at times without closing my browser for hours... and it hasn't crashed or died. It is a bug, and it is being/will be looked into. If you want to help this process, you can help with testcases, providing patches, and other data to make the job easier for the developers you're taking for granted. But, just whining, "fix it fix it", isn't going to help get it fixed or anything else, and is only going to cause bugspam. I'm sorry if you don't think Mozilla development is fast enough.... but, I'm afraid, I personally don't see this bug as a priority when compared to other, more crucial, bugs. Please forgive the bugspam. -[Unknown]
(In reply to comment #58) [...] > I'm afraid that comments like that aren't very helpful. This isn't killing > anyone, and I've browsed with large numbers of tabs at times without closing my > browser for hours... and it hasn't crashed or died. > > It is a bug, and it is being/will be looked into. If you want to help this > process, you can help with testcases, providing patches, and other data to make > the job easier for the developers you're taking for granted. > > But, just whining, "fix it fix it", isn't going to help get it fixed or anything > else, and is only going to cause bugspam. I'm sorry if you don't think Mozilla > development is fast enough.... but, I'm afraid, I personally don't see this bug > as a priority when compared to other, more crucial, bugs. > > Please forgive the bugspam. > > -[Unknown] Well, please forgive /my/ bugspam, but even if it hasn't killed anyone yet, it is choking me almost to death every day, sometimes several times a day. OK, OK, I know the workaround: close Firefox and restart it, and with Session Saver installed it will even reload my tabs. But Mozilla can hardly advertise "Warning: if Firefox slows your system down to an asthmatic snail's crawl, the solution is to restart the browser", can it? -- I mean, so that every newbie user will be aware of it. I feel this bug won't be easy to track down, and I'm not competent to help, but this progressive slowdown of my whole system isn't exactly making me happy. Oh, well, as long as it isn't "resolved" without "fixed", I guess people are still working on it. FYI: Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Windows XP 5.1.2600 with SP2 Processor X86 Family 6 Model 9 Stepping 5 GenuineIntel ~1300 MHz At the moment 337 MB swap are in use for 196 MB RAM (or 256 MB, sources apparently conflict), of which 15 MB are free. FF is using 71 MB, TB 10 MB, NAVAPSVC 7 MB, Explorer.exe 6 MB, no other "image" takes more than 3 MB apiece. I'm feeling the slowdown though it's still bearable. I'm voting for this bug and (since I can't help in any other way AFAICT) praying that you savvy guys will find what bugs us all and how to cure it.
(In reply to comment #59) > ... I've not been able to reproduce things to this degree - whether with my work laptop (which has around the ram you mentioned) or with my desktop (which has 512 mb of ram) - on both of which, I often have Firefox open for 8 hours or more, and usually have anywhere from 1 to 8 tabs open. The laptop runs Windows XP, and the desktop (for development reasons) runs 2003 Server. Indeed, on both of these I am often running Visual Studio, Outlook, and other programs that have large footprints. The only time I ever experience slowdowns is when I leave my computer for long enough that Firefox's memory gets trimmed. (which is a totally different bug, and it recovers quickly.) Yes, after closing tabs memory usage does not go down. This does not bother me... because it causes me no problems. However, even if I open another round of tabs, all going to various websites with flash and other things on them, it doesn't go higher still. In fact, it seems to at this point free up a bit (possibly because it shifted memory through Flash, or similar? Guessing here.) I think there is more to this bug than meets the eye. If you could give links to open in tabs, how many, at what times, when to close them, and your ram usage numbers at each point... it probably would be helpful. (see comment #56.) Thanks, -[Unknown]
You all wanted a test case? Try opening a bunch of really big fusker preview links (fusker.lewww.com; caution-- very NSFW) in tabs. Repeatedly. There, I said it: pr0n browsing breaks Firefox. To generalize: opening lots of tabs with lots (hundreds) of large image files causes this behavior very quickly for me. Memory is not returned to the system until I quit the browser. Note that this is just a way to bring it on quickly-- it happens regularly for me in normal browsing as well; here are a few scenarios: * When I read my daily blogs, I open a lot of tabs to read later. * ... and then doing this many times a day without closing the browser. * I share my computer with my fiance, who insists I leave her windows open for her. Hence the browser never gets closed. * practically anything involving large image files If there were a magical talkback build, or an extension I could install that could track memory usage over the browser session, I'd submit my data, if only to prove that this exists and is a serious bug.
(In reply to comment #60) > (In reply to comment #59) > > ... > > I've not been able to reproduce things to this degree - whether with my work > laptop (which has around the ram you mentioned) or with my desktop (which has > 512 mb of ram) - on both of which, I often have Firefox open for 8 hours or > more, and usually have anywhere from 1 to 8 tabs open. > > The laptop runs Windows XP, and the desktop (for development reasons) runs 2003 > Server. Indeed, on both of these I am often running Visual Studio, Outlook, and > other programs that have large footprints. The only time I ever experience > slowdowns is when I leave my computer for long enough that Firefox's memory gets > trimmed. (which is a totally different bug, and it recovers quickly.) > > Yes, after closing tabs memory usage does not go down. This does not bother > me... because it causes me no problems. However, even if I open another round > of tabs, all going to various websites with flash and other things on them, it > doesn't go higher still. In fact, it seems to at this point free up a bit > (possibly because it shifted memory through Flash, or similar? Guessing here.) > > I think there is more to this bug than meets the eye. If you could give links > to open in tabs, how many, at what times, when to close them, and your ram usage > numbers at each point... it probably would be helpful. (see comment #56.) > > Thanks, > -[Unknown] It probably would be useful, but alas, I've had a blue-screen reboot just now, and anyway, I'm not logging everything I do. IIRC, I had about 25 tabs open including the one for Bugzilla; more than half were pointing to various pages of the deviantart.com site (which is a kind of collective "art gallery"); two were local (file:///something), one at www.spamcop.net, one at sourceforge.net/my/, one or two at mozillazine, etc. The deviantart tabs had seen quite a lot of activity; the others not so much. Also, additional tabs had been opened and closed several times for mozillazine topics I'm watching. That's about all I can remember. Yes, me too I think there's more to this bug than meets the eye, but it's been a long time since the time I was a "real" system programmer (let's say I was on mainframes about the time when medium-sized businesses started switching over from CP/M to DOS). I'm not competent anymore to go debugging this kind of things. IIRC, when my system grinds to a slow crawl, restarting FF will reclaim about 60% of the latter's memory usage and make the system "live" again.
Debian Bug report logs - #280586 mozilla-firefox: leaks like hell and gets slower and slower http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280586
I filed bug 258240 some time ago, which seems to describe similar problems. Can anyone confirm it to be a duplicate or a seperate issue? It has guidelines for reproducing. It is really getting out of hand on my system. Recently, I had Mozilla 1.7.2 eat a whopping 1.16 GB of virtual memory. Ok, so I had been surfing for a few days without restarting (Mac user), but that much VM is ridiculous.
Product: Core → Mozilla Application Suite
As this occurs on Firefox as well as the Suite, shouldn't component be switched to Core?
No, because this code isn't in the core - there is separate code to do this stuff in the Suite and in Firefox. This bug must at least be 2 separate issues (in Firefox and the Suite). In fact this bug is probably describing multiple issues in both, so I would imagine it's probably going to be pretty much impossible to fix "it". As and when someone actually tracks down exactly what the causes of these problems are then the bug can be moved to the right place, or (more likely) separate bugs can be filed in different places. But there's no point in shuffling bugs around without actually diagnosing the problem (rather than just discussing the symptoms).
OK, so no easy tracking down the bug. Could this bug be related to bug 256822, then?
(In reply to comment #67) > OK, so no easy tracking down the bug. > Could this bug be related to bug 256822, then? As mentioned above (comment #59) I'm seeing this in FF 1.0 release. IIUC the comments to bug 256822, the latter was fixed at some earlier point in FF 1.0 beta. Regards, Tony.
Can someone use an instrumented allocator and put some useful data in this bug? Are we just hurting from memory fragmentation here preventing the allocator from munmap()ing free()d space, or are we suffering from other issues like incomplete freeing of frame-recyclers or other such woes? The glibc allocator uses mmap for most allocations, if I recall my instrumented tests from 1999 correctly, so it should be able to trim. Where is the memory going? We have lots of tools like spacetrace and the like to help figure this stuff out, so someone should step up and do the testing work, IMO. (I think this is probably a core issue, since we hear of it in embedding apps as well.)
(In reply to comment #33) > Isn't this really a meta bug? There must be a number of other bugs that cause > this problem. Just a loose thought just in case. In addition to using excessive vram & ram, FF (on OSX 10.3.6) seems to be using more threads that'd I'd have expected. E.g. currently I have 2 windows with 5 and 2 tabs respectively open. FF is using 165Mb RAM and 450Mb VRAM but also 19 threads. Its just possible that old threads holding resources aren't being killed off, blocking the resources from being reclaimed -- ? (In general threads seem to be allocated per new window (regardless of having content) or tab (generally when it gets content), and are killed as the tab or window is closed, but the behaviour isn't always as one-on-one as you'd expect if a strategy that simple were employed.) A long shot and might be a wild goose, but there you go. This needs (a lot of) work, but I'd like to pop it in while I remember as I'm inclined to get sidetracked... General comments on the discussion: btw #43 - its a feature I like too (along with being able to move tabs amongst windows and save tab groups). It doesn't solve this problem per se, but it does reduce the impact of this and any other crash/lock-up/forced-restart on those who need sets of sites open. (#44: different users have different needs - I leave specific sites open for days.) I also agree that this appears to be a very old bug that's persisted.
(In reply to comment #33) > Isn't this really a meta bug? There must be a number of other bugs that cause > this problem. Just a loose thought just in case. In addition to using excessive vram & ram, FF (on OSX 10.3.6) seems to be using more threads that'd I'd have expected. E.g. currently I have 2 windows with 5 and 2 tabs respectively open. FF is using 165Mb RAM and 450Mb VRAM but also 19 threads. Its just possible that old threads holding resources aren't being killed off, blocking the resources from being reclaimed -- ? (In general threads seem to be allocated per new window (regardless of having content) or tab (generally when it gets content), and are killed as the tab or window is closed, but the behaviour isn't always as one-on-one as you'd expect if a strategy that simple were employed.) A long shot and might be a wild goose, but there you go. This needs (a lot of) work, but I'd like to pop it in while I remember as I'm inclined to get sidetracked... General comments on the discussion: btw #43 - its a feature I like too (along with being able to move tabs amongst windows and save tab groups). It doesn't solve this problem per se, but it does reduce the impact of this and any other crash/lock-up/forced-restart on those who need sets of sites open. (#44: different users have different needs - I leave specific sites open for days.) I also agree that this appears to be a very old bug that's persisted.
Screenshot 1 of 2: Task Manager screen, sorted by RAM occupation. FF, then (far behind) TB and Explorer, come at or near the top for both RAM and swap usage. Note that although 30 tabs are open, FF has only 8 threads, so for me threads are not a problem.
screenshot 2 of 2: about:cache screen, taken at a few seconds' interval from the preceding one. Notice the "memory cache" using almost 10 times the "maximum". The delay between both uploads is due entirely to the general system's (including, but not limited to, Firefox's) slowness at this point.
(Followup to comment #73) [...] > Notice the "memory cache" using almost 10 times the "maximum". [...] After posting those 2 screenshots, I went on to look at what was kept in that oversize "memory cache". All I saw were pictures, most of which had been fetched only once. I wonder why FF cannot discard the "least recently used" picture whenever not doing so would bring (or keep) the memory cache size over the maximum. ... And sorry for answering myself, but I thought you big brains might want to know. Best regards, Tony.
I can only confirm Tony's observations with about:cache, only that it's much worse here. Here's the story behind this shot, in case anyone is interested: I recently had to do some heavy image browsing with unusually large images (not abnormal though -- think around 2048x2048). I displayed a bunch of them, don't know exactly how many, but maybe around 40. I then noticed something was VERY wrong as Windows XP started thrashing like mad just to open my mail client while Firefox was open (and I didn't want to close it at the moment). It kept on thrashing for a while, and then a "balloon tip" appeared telling me that "Windows is running low on virtual memory and is now increasing the amonut of virtual memory". Whoa, that means it must have run out of 512 MB + 1 GB memory. I then noticed what's shown in the screenshot. I'm also noticing this regularly at work where I rarely have to turn off my computer, and is often required to restart Firefox even without image browsing. It seems like it doesn't know when it's safe to release memory allocated for the images? Also, why does it say "inactive storage = 0 KB"? I have nothing open, shouldn't a whole lot of that storage be "inactive"? Or am I misunderstanding the definition/purpose of that line? An excess amount of threads were discussed earlier, but I think these things are unrelated, unless it's some threads that keeps those images allocated and keeps living when they should be "dead". :-/ Hard to tell, maybe I can diagnose this further with a better task manager that list more info about threads, not sure about that... Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.7.5) Gecko/20041108 Firefox/1.0 I unfortunately forgot to list the cache entries in the memory cache to see what was taking up all this memory. :-/ Might try to reproduce this and do that later.
(In reply to comment #73) > > Notice the "memory cache" using almost 10 times the "maximum". The problem with the memory cache maximum being exceeded is bug 250558.
(In reply to comment #76) > (In reply to comment #73) > The problem with the memory cache maximum being exceeded is bug 250558. ======================================================== Right. If the memory cache did not exceed the maximum, then it couldn't use too much memory, could it? For that reason, I think bug 250558 is the real one. ======================================================== As for this "bug", I'm not sure whether not releasing a cache is a bug or a feature. You decide. And contrary to other reports, I find that FF 1.0 does release memory cache, although not necessarily all of it, and not necessarily immediately or at predictable times. I also note that other programs, e.g. MS Word for Windows, also retain memory for a while after closing files.
(In reply to comment #77) [...] > And contrary to other reports, I find that FF 1.0 does release memory cache, > although not necessarily all of it, and not necessarily immediately or at > predictable times. I also note that other programs, e.g. MS Word for Windows, > also retain memory for a while after closing files. Maybe the memory cache is used for several purposes, to cache different things. I have the impression that memory cache _used for picture files_ is never released. I haven't tested it thoroughly, so I might be wrong. Best regards, Tony.
(In reply to comment #78) > Maybe the memory cache is used for several purposes, to cache different things. > I have the impression that memory cache _used for picture files_ is never > released. I haven't tested it thoroughly, so I might be wrong. I have tested thoroughly. Type 'about:cache?device=memory' in the address window. When you close tabs, memory is released immediately, unless it is below the maximum storage size, in which case the memory is marked as inactive but not released. Not releasing cache is probably a feature, not a bug.
Not releasing cache up to the maximum cache size *might* be a feature (though it should probably *eventually* release it just to be a good citizen, and because reallocating will probably statistically be faster than paging the memory back in anyway). And not releasing cache above the maximum cache size is probably a *different* bug, as mentioned. I suspect that might be happening because at some point all that memory actually *is* in use (i.e. displayed, not cached), and FF is probably forgetting to unmark it or trim the cache or something when the tab closes. However, the weird thing is that holding onto *unused* cache pages should normally be harmless, because untouched memory will just be paged out (once) when the memory is needed elsewhere. It's a bit of a mystery why that doesn't seem to be happening. But... if the way the cache is used causes most of the allocated pages to periodically be touched for some reason (even though they are "unused"), then not releasing cache pages *is* a bug, because it will thrash the system, as observed here. So... is it a bug not to release unused cache pages? I can't say because I don't know enough about Mozilla/Firefox's guts.
I think one should look at the big picture here -- when I'm browsing more or less picture heavy pages and not closing the browser between sessions, at least I have to shut it down after a while since the memory usage goes far above 100 MB and it causes considerate and noticeable slowdowns of my system as I'm switching from/to the Firefox application. Maybe it's not directly tied to this bug, but in either case I think to give users a better experience from Firefox memory hogging, it should more aggressively release memory allocated for the cache, *especially* if it's going above the maximum. I can't see how it's recommended behavior in any case to have it hog memory for hours beyond you've closed all former tabs. We need to remind ourselves why caches exist. They're there to speed things up. When the cache increases too much for a system to handle so it slows things down instead, it's defeating the purpose of it, and I have definitely seen that happening. IMHO, in a perfect world where there existed developers to fix bugs like these, Firefox would allocate a percentage of system memory for its cache and if that's exceed, start to throw the oldest cached data out from it. Who cares if there was a chance the user would've revisited a page later on and had to *gasp* let the internet connection take care of it. I doubt a user with memory shortage would.
Again, I'm just speculating, but you have to look at another big picture: during the time when all the pages/tabs actually *are* open, you're inevitably going to have this same problem. Having the browser say "sorry, you can't open that page, it would put memory usage above your cache limit" would be even more annoying. This issue then appears when you ask yourself what to do when a tab/page is closed. Do you start counting those images as belonging to (and being counted in the memory usage of) the "cache" at this point or do you just throw them away (I very much doubt that they are moved in memory... the only sensible thing to do would be to have the cache and the resident image be in the same and just marked/indexed differently). The answer would depend on what is meant by the cache limit number. I strongly suspect that the root cause of both this bug and the other one referenced above is some flaw in what happens at this decision point. It's certainly not an easy decision to make without scaning the whole resident storage area for pages/images (i.e. "garbage collecting"... which would be too expensive to do every time you stop showing an image, but might need to be implemented to happen periodically in order to solve this efficiently). If I was sufficiently familiar with the codebase to a) know how the memory caching/resident memory scheme is *supposed* to work, and b) find the spot in the code at which tabs are closed (or more helpfully the subsequent code where the release of the images/text is performed), I'd be happy to go grunge through and see if I could find anything... as it is that would take more investment than I'm able to make at this time. Unless someone wants to answer those 2 questions...
"Again, I'm just speculating, but you have to look at another big picture: during the time when all the pages/tabs actually *are* open, you're inevitably going to have this same problem." Hmm, yes, obviously it needs to allocate memory for the pages it displays, if that's what you're saying. I wasn't implying this should be somehow countered. If you're browsing a 100 MB page, too bad, it might become dog slow. What I'm discussing is about what's going on when you *don't* have anything open. When you afterwards close that page and go to Google in the single Firefox process in the single tab, should it then let Google eat 100 MB too? And if you've browsed more pages, should it then let Google eat 150 MB? This is where my problem is. I'm not in a hurry for it to release unused cache memory, either. As long as it does it at some point in a reasonable amount of time, I'm happy. I guess the frequency it does a garbage collection, or whatever the solution might be, can be discussed and adjusted when there's a solution for this. It's hard to tell before we have a solution for it and know how costly it is in CPU time to run. "Having the browser say "sorry, you can't open that page, it would put memory usage above your cache limit" would be even more annoying. " I'm not saying it should say anything. It should use the memory it needs to view the pages. However, as far as my testing as shown it seems to release barely any memory at all, at any time, until you kill the process. I'd be interested in knowing why this is so. I would of course love having developers join the bug giving thoughts about this, like where the problem actually seems to be in the browser, and trying various solutions out, but it seems like this is a very hard thing to crack. :-(
For what it's worth, I can confirm the effect, but not the problem. =================================================================== FF 1.0 has been running for a while, with several (about 12) miscellaneous tabs open. Ordinary Web pages, with some but not a lot of graphics. This much is easily duplicated. Here are my data. 'Mem usage' and 'VM size' refer to the FF process (from Task Manager). 'Phys. Mem.' (available memory) and 'Commit Charge' (committed memory) are for the OS (from Performance page of Task Manager). 'Max. cache' and cache In use' are from FF about:cache tab. All values in MB. =============================================================================== Mem usage; VM size; Phys. Mem.; Commit Charge; Max. Cache; Cache in Use 114.1 109.9 36.3 299.2 18.4 45.7 open Power Point with 8 MB file 74.9 110.0 85.7 299.2 18.4 45.7 minimize window 2.7 110.0 145, rising 299.7 18.4 45.7 reopen window 36.1 110.0 171.9 229.7 18.4 45.7 ============================================================================ Conclusions: 1. Cache memory is not limited by maximum size. (Minor? bug 250558) 2. A large amount of memory (up to 114 - 46 = 68 MB) was used for code and/or data. 3. This is similar to the very high memory use reported by many users. 4. Much or most of the 68 MB of memory is released on request, either because of starting another program or when minimizing the window. 5. On my system, neither the large memory cache reported by about:cache nor the memory use reported by the Task Manager has ever caused a significant slowdown or any other problem. If necessary, memory is swapped or released gracefully. Question: Does FF really refuse to release memory when it is supposed to? Is there hard confirmation of this? Is this really a FF bug? ========================================================= FF 1.0, 50 MB default swap space, Java, JavaScript enabled. Essentially no plugins installed or active. Win XP, version 2002 SP1, 384 MB memory, 665 MHz Pentium.
(In reply to comment #84) > For what it's worth, I can confirm the effect, but not the problem. > =================================================================== [...] > FF 1.0, 50 MB default swap space, Java, JavaScript enabled. Essentially no > plugins installed or active. > > Win XP, version 2002 SP1, 384 MB memory, 665 MHz Pentium. FWIW, on my system, when the _total_ swap use by all program exceeds something like 450 MB the system gets really very slow; and FF and TB both start losing focus (sometimes several times) whenever they do anything. I believe that the problem is most acute on pages havily laden with images, such as the "art galleries" at http://www.deviantart.com/ etc. I'm using: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0", XP 5.1.2600 SP2 "Build 2600.xpsp_sp2_rtm.040803-2158 (Service Pack 2)", processor "GenuineIntel Family 6 Model 9 1.3 GHz Stepping 5", total physical RAM 191 MB, my 37 GB disk is about 2/3 free, and I've set my swap settings quite high (minimum 512, maximum 1024: in typical Windows fashion, those settings are hidden several levels down in some obscure Control Panel item) to avoid seeing Windows "extend" it. If the Windows maximum is too low it's even worse: then when that maximum is (almost) reached, the program which last requested memory (usually FF but it can be almost anything) gets silently killed. With a little bad luck it's a blue-screen halt.
(In reply to comment #85) > I'm using: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) > Gecko/20041107 Firefox/1.0", XP 5.1.2600 SP2 "Build > 2600.xpsp_sp2_rtm.040803-2158 (Service Pack 2)", processor "GenuineIntel Family > 6 Model 9 1.3 GHz Stepping 5", total physical RAM 191 MB Forgive me this, but... you really shouldn't be using Windows XP SP2 with so little physical RAM. Your 192 MB (or 191, but that's an odd number.) is only just above the memory requirements, and I remember when I first upgraded to XP (read: while I was still using Internet Explorer and hadn't heard of Firefox yet!) I had a WORLD of trouble with about the RAM you had. I solved it by jumping to 640 MB, and it's been dreamy ever since (well, I had a stick go bad, and I'm back at 512, but it's still running well.) Even by itself, XP takes a good chunk of that RAM. If you're multitasking large-footprint programs with so little, you're really asking for slowdowns - whether you use Firefox or Internet Explorer or even Opera. I could easily pickle a system like that by running my usual programs: Microsoft Visual Studio .NET 2003, Microsoft Outlook and/or Thunderbird (have about the same footprint for me), Apache 2, MySQL, Firefox, and possibly other programs. Let's not even *mention* VMware. Now, I realize you're probably not running all of those development tools, but my point is that this may not be *exactly* Firefox's fault entirely. I strongly recommend you invest some money in more memory; you can get 256 megs for a decent price, using www.pricewatch.com or going to your local computer store. I even see $45 for PC3200 DDR 512MB there right now, which sounds quite good to me (but I haven't shopped for memory in a few months, so if you're unsure I suggest you ask someone else.) Just my advice; I'm not saying this isn't an issue that could be fixed in Firefox, just saying that a significant level of the problem isn't with Firefox. Obviously not everyone (maybe/probably not even you) is going to go out and buy more memory if Firefox slows their system. By the by, I notice both attached screenshots show "58 megs"... I generally seem to notice Firefox hover at that on my system. So, yes, it has a large footprint. -[Unknown]
I have 512MB ram on my linux laptop and this bug is a serious problem for me when working on my photo albums. The laptop starts thrashing bad enough that on the old kernel ( 2.4.x ) I needed to hit the power button. Not sure yet whether 2.6.x kernel handles it better. If there's a problem, it will hit everyone sooner or later no matter how much memory they have. And there is a problem.
(In reply to comment #86) (Off-topic) [...] > Forgive me this, but... you really shouldn't be using Windows XP SP2 with so > little physical RAM. [...] Yeah, sure, but Microsoft says it's soon not gonna support anything else, and I can't downgrade from here, can I? (I can't reinstall because what I have is not a Windows CD but a Windows "hidden VFAT partition".) Anyway, the author of comment #87 has a lot more RAM than I do and he suffers from the same problems. Nothing to forgive to your just expressing an opinion, which, BTW, is off-topic. About adding memory to this laptop computer: I don't know how to; maybe my spare parts dealer will; but won't it void the warranty? (I just had the HD replaced under warranty and I don't want to lose whatever remains of that warranty.) Best regards, Tony.
Perhaps this is related to bug#130157
(In reply to comment #88) > Nothing to forgive to your just expressing an opinion, which, BTW, is off-topic. Hardly. I still don't think this is being overdramatized. No large application I've ever seen lets all its memory go at once; and I've always experienced Firefox to trim its memory usage beautifully (sometimes too much so) when it is asked to. My opinion and comments are not off topic, if they express that the problem isn't so much with Firefox as with your low amount of system memory. When it gets ever so bad, does minimizing help? As has been reported above in this bug, if you minimize Firefox for a decent amount of time, it starts dropping everything. I mean, I just minimized it and it went from 25k to 2k to 10k. It's now stable at 10k.... after a bit it has started to rise, up to 15k. Minimizing it again shoots it down to 1.5k. Does yours stay high on minimize? > About adding memory to this laptop computer... You didn't mention it was a laptop, but you should still be able to add memory to it. For most models, it doesn't even mean opening anything but a little compartment on the bottom, and if that'd void your warranty I'm sure you can get the manufacturer or an approved party to add the memory for you. -[Unknown]
(In reply to comment #90) > (In reply to comment #88) > > Nothing to forgive to your just expressing an opinion, which, BTW, is off-topic. > > Hardly. I still don't think this is being overdramatized. No large application > I've ever seen lets all its memory go at once; but do they allocate ten or twenty times their stated "maximum" in the first place? > and I've always experienced > Firefox to trim its memory usage beautifully (sometimes too much so) when it is > asked to. I haven't, and I'm not the only one. (BTW, how do you "ask" it to?) When browsing pages with lots of images, I've seen FF gobble hundreds of MB all by itself and never release them to the OS. Here's an experiment for you to try: browse to http://tonymec.deviantart.com/favourites/ (my favourite artwork) and keep clicking on "Next 24" at bottom right whenever a page is fully loaded. When you see a picture you like more than others, or think you might if you could see it at more than thumbnail size, click right on it, then "Open link in New Tab" to see it medium-size, and then click on the picture again for full-size (then close the new tab and go back to the other one to continue browsing the art gallery). Tell me what happens after you get to the end of the gallery. > My opinion and comments are not off topic, if they express that the > problem isn't so much with Firefox as with your low amount of system memory. I can't believe that this is "no FF bug". Are you trying to push it to RESOLVED WONTFIX? Or RESOLVED WORKSFORME? For me it does NOT work and some people with 512M or more are just in the same sad pickle as I am, see the posts above. > > When it gets ever so bad, does minimizing help? As has been reported above in > this bug, if you minimize Firefox for a decent amount of time, it starts > dropping everything. I mean, I just minimized it and it went from 25k to 2k to > 10k. It's now stable at 10k.... after a bit it has started to rise, up to 15k. > Minimizing it again shoots it down to 1.5k. Does yours stay high on minimize? Yes. Even if I minimize everything then go to bed for 8 hours (with the computer on but only the desktop showing (or not) on its (possibly sleeping) screen. The only way to reclaim the memory for the OS (AFAIK) is to close Firefox completely (click on the white-on-red X at top right of each FF window and wait for "firefox.exe" to disappear from the Task Manager's list of processes). > > > About adding memory to this laptop computer... > > You didn't mention it was a laptop, but you should still be able to add memory > to it. For most models, it doesn't even mean opening anything but a little > compartment on the bottom, and if that'd void your warranty I'm sure you can get > the manufacturer or an approved party to add the memory for you. > > -[Unknown] Ha, ha. The manufacturer is in the Netherlands, I'm in Belgium. The retailer which sold me the computer (two hours from here by bus each way if I'm lucky and don't wait, three if I just miss a bus) won't take any responsibility, it's "let the manufacturer handle it". My hard drive crashed last fortnight (under warranty), it was a hell of a hassle to get it replaced, and to boot, Windows came back in a different language than it was before. Do people in Quebec city send their cars to the manufacturer in Detroit to place snow tires or even install a GPS radio? No. I'm not going to send my computer from Brussels to 's-Hertogenbosch once more just for a memory chip, especially not if Firefox is the only program which has (or causes) problems with my memory size. It almost sounds to me (stretching the matter just a little bit) as if you were trying to convince me that I ought to go back to IE. Alas, except for this bug, FF is so much more to my liking (even more so than NS7, another Mozilla browser) that I won't. ... Inhale ... Exhale ... Relax ... I see a little "door" (about two inches by four or some such, with one screw where the key slot would be) on the bottomside of this computer. Maybe that's what you're talking about. I might ask my spare parts retailer about it (city centre, a quarter of an hour from here by tram each way, still less than half an hour if I have to wait; but packed like sardines every rush hour). But even if I do, let no one take it as an excuse for not having this bug fixed. Best regards, Tony.
(In reply to comment #91) > ... Inhale ... Exhale ... Relax ... Dude, breathe. So you can't get memory so easily... saw-ry. Don't take this so personally. I did as you asked. Browsed about in your gallery (although it was a bit risque) and clicked on several of the images, until I got to about 120 kilobytes of ram. So far, I feel Firefox is acting completely normally. I think closed all the tabs for deviantart, and checked about:cache... it described 54 kilobytes of ram as being used, and I still belived it. Funny, the way you talk you'd think that was a stupid thing. Anyhow, I then went a minimized my browser, with the task manager open. Bam. 5 kilobytes used. Instantaneous. I restored my browser, and it crawled back to 56.... perfect. It's at 54 now. Another minimize takes it down to a nice 20k. And for now, at least, it is staying there. And after all that 120 k of ram, too. Is config.trim_on_minimize set to anything in about:config? Does creating a new (clean) profile change this behavior at all? -[Unknown]
(In reply to comment #92) s/kilobytes/megabytes/ I just tested it on another person's computer and made a discovery; I'm using an *official* build, with that nice firefox logo, and I get the trim just fine. The other computer I tested is using an unofficial (MOOX M2) build. It didn't trim on minimize, at all... where mine drops to 5 immediately, it stays the same. Are you using an official or unnofficial build? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 -[Unknown]
(in reply to comment #92 and comment #93) I use "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0" (as copied & pasted from the about: page); but with 10 tabs ATM and 30 extensions. When I minimize it, I don't see any drop, certainly not to 5MB, which is less that what it takes even at load. The option you mention is not listed in about:config. I don't want to mess with profiles if I possibly can leave the default alone (though I know the theory: invoke "firefox -ProfileManager" from the command-line, since install didn't create the shortcut, unlike with TB.) Best regards, Tony. P.S. [OT] I'm not sure what you call /risqué/ (Is the Venus of Milo risqué? The Aphrodite of Cnides? Michelangelo's David? Botticelli's Birth of Venus? Ingres's Grande Odalisque?) Oh well -- beauty is in the eyes of the beholder. <shrug />
Some thoughts: 1) This _is_ a bug. There are 183 Votes on it... 2) I restart FF quite a lot to get rid of it. The restore-function of Tabbrowser Extension helps though. 3) I do not have the option config.trim_on_minimize on FF 1.0 4) This seems to bee some kind of core Problem. TB has the same. If you have it running for a realy long time. Let's say a week or so and get a lot of attachments it starts getting realy big. So You have to restart it, to release the mem. 5) I have 256 MB on Win2000. This should be enaugh. I have the feeling that a lot of the devs have a gig or so on their machines, so they don't care. 6) I don't see any problem for relesing cache in Memory _realy_ fast. We have a cache on the HD. So if I set my Memory-Cach to 1 MB I'll get some more disk-activity, but I'll get that anyway because win is swaping like hell. BTW, this is about cache not about the Memory I need to display a page.
(In reply to comment #95) I mostly agree with you, of course. [...] > 2) I restart FF quite a lot to get rid of it. The restore-function of Tabbrowser > Extension helps though. Or of Session Saver for those who don't want the bloat of TBE. [...] > 6) I don't see any problem for relesing cache in Memory _realy_ fast. We have a > cache on the HD. So if I set my Memory-Cach to 1 MB I'll get some more > disk-activity, but I'll get that anyway because win is swaping like hell. BTW, > this is about cache not about the Memory I need to display a page. ATM, my about:cache says Memory: maximum 11264 KiB, used 23076 KiB Disk: maximum 50000 KiB, used 49991 KiB This is much lower than my record. Notice that FF respects is disk cache maximum but not its mem cache maximum. Here it exceeds it "only" by slightly more than 100% and my "total swap use" as shown by Task Manager is only 397 MB; but I've recently restarted FF when the "total swap" was at 520 or so; AFAICT all the difference between then and now was due to FF. So: I believe it would be good to give back memory to the OS whenever possible but AFAICT FF is not doing it, and after some time it is so swollen that Windows is swapping like crazy and everythings runs at an asthmatic snail's pace. When that point is reached, the advantage of keeping some Internet data in memory is lost since the time lost by seesaw-swapping exceeds by much what might be gained by not reloading. (People on 56K lines might have different tradeoffs though -- mine is ADSL, 3M down, 192K up -- but IIUC the difference is just that the tradeoff point will move up or down: there will always be a tradeoff.)
I played a bit with the option browser.cache.memory.enable. Didn't realy notice a difference except the memoryuse went down to nice 37MB when I closed the tabs. :-) I have a two questions though: 1) Why isn't there an option: browser.cache.memory.capacity? I didn't realy notice when it was gone. But there was one in some long time ago - was there?? 2) Why is chrome:// - stuff cached? This is odd, because when disable the mem-cache, there is no disk-activity. (Maby this is the win-disk-cache)
(In reply to comment #97) > I played a bit with the option browser.cache.memory.enable. Didn't realy notice > a difference except the memoryuse went down to nice 37MB when I closed the tabs. :-) > I have a two questions though: > 1) Why isn't there an option: browser.cache.memory.capacity? I didn't realy > notice when it was gone. But there was one in some long time ago - was there?? > 2) Why is chrome:// - stuff cached? This is odd, because when disable the > mem-cache, there is no disk-activity. (Maby this is the win-disk-cache) > > That gives me an idea: let's try disabling the memory cache (in about:config) and increasing the disk cache (in Tools -> Options -> Privacy -> Cache). This ought to allow saving stuff locally but without gobbling insanely huge lots of real and virtual memory. Something (my little finger, as we say in French) tells me a better equilibrium just might be struck. (A workaround to the bug?) Best regards, Tony.
w2k sp2, firefox 1.0, 1 GB RAM firefox regularly hits +200 MB Mem Usage (Task Manager) usually locks up hard before hitting 300 MB Mem Usage i have noticed that firefox's endless Mem Usage growth correlates with files that are downloaded with the download manager. i just downloaded a 10 meg file with firefox and firefox Mem Usage jumped more than 10 megs. after the download completed the RAM used (per Mem Usage) was not released. now i'm starting a 14.6 meg download. firefox Mem Usage just jumped 10 megs and as the download proceeds firefox Mem Usage continues to increase. the download is almost complete (200 kb remaining) and firefox Mem Usage is 2 megs higher (12 megs total since just before beginning the download). the download just completely - yikes! - firefox Mem Usage just jumped another 4 megs the moment the download completed. so, total Mem Usage increase for the 14.6 meg download was ~16 megs. i'm reporting this because i haven't seen anyone report this particular nuance of the firefox's endless Mem Usage growth. i would be very appreciate if someone else would endeavor to confirm this same behavior on their system and report back here. thanks, david
Firefox Bug 250558 just got a whiteboard comment mentioning this bug as its Suite version. Maybe we ought to make the reference two-way? And maybe even move all Firefox-related comments and attachments over to there (if possible)?
Some expiriance about FF 1.0 Behavior: - (Mem-Cache turned off)The Disk-Cache is not triggerd during Page-Load. So if the same image is on a page several times it is loaded several times from the Webserver. - I must admit though that FF does free a lot of mem minimizing and reopening. (A minimize while in background - plugin would be fine ;-))
Sorry, but what is config.trim_on_minimize supposed to do? Is it still able to free memory once the limit has been hit? (see bug 213391 - comment 23) - doesn't free anything for me but it's worth a check. If it only frees memory from the "inactive storage", the feature is still useful, but then it should be triggered by other conditions: when the _system's_ memory is growing low, or when the user has been inactive for a while. With a linux desktop and several workspaces, I hardly ever minimize any window.
*** Bug 278959 has been marked as a duplicate of this bug. ***
Is it possible that bug 130157 is a duplicate of this or vice verca. I would propose the following to distinguish between standard memory leaks and bug 130157: 1. open a page you suspect that is causing the memory leak 2. note the memory used (in Windows 'Mem Usage' and 'VM Size') 3. close the page (not all memory will be released to the OS due to bug 130157) 4. open the page again 5. note the memory used - it shouldn't be much more than in point 2. If after repeating steps 3-5 you notice that memory (especially 'VM size') is constantly growing, then it should be a memory leak. Often after repeating step 3-5 many times (e.g. 7-10) memory usage might go down, after increasing for the previous loops. There are currently about 380 bugs with MLK in the keywords, that need to be fixed.
(In reply to comment #104) > Is it possible that bug 130157 is a duplicate of this or vice verca. > > I would propose the following to distinguish between standard memory leaks and > bug 130157: [...] > If after repeating steps 3-5 you notice that memory (especially 'VM size') is > constantly growing, then it should be a memory leak. Often after repeating step > 3-5 many times (e.g. 7-10) memory usage might go down, after increasing for the > previous loops. > > There are currently about 380 bugs with MLK in the keywords, that need to be fixed. Couldn't this "slow but constant growth" of used VM be intrinsic to the way the heap is managed? On some other bug (I forget which one), it was said that if you free something in the heap but not at its top, no memory is returned to the OS. I can imagine that after several hours of continuous browsing, the heap might contain a lot of such "holes", making it resemble, let's say, a kind of meringue or styrofoam: each hole is not necessarily very big, but there are so many of them that in total there are more "holes" than "stuff" -- and (since, IIUC, heap memory still in use cannot be moved to a different address) the only sure way to "compress" it again is to restart FF (in my case I use the Session Saver extension, so the same contents and back-and-forth histories get reloaded into the same tabs).
*** Bug 280453 has been marked as a duplicate of this bug. ***
(In reply to comment #105) > Couldn't this "slow but constant growth" of used VM be intrinsic to the way the > heap is managed? On some other bug (I forget which one), it was said that if you > free something in the heap but not at its top, no memory is returned to the OS. > I can imagine that after several hours of continuous browsing, the heap might > contain a lot of such "holes", making it resemble, let's say, a kind of meringue > or styrofoam: each hole is not necessarily very big, but there are so many of > them that in total there are more "holes" than "stuff" -- and (since, IIUC, heap > memory still in use cannot be moved to a different address) the only sure way to > "compress" it again is to restart FF (in my case I use the Session Saver > extension, so the same contents and back-and-forth histories get reloaded into > the same tabs). The behaviour you describe is called "memory fragmentation" and is (unfortunately) completely normal. There's no real cure for it. If you know one that really works, you could be richer than Bill Gates. See bug 276342 for a few ideas that were useful for me in other projects, but it will never solve the problem completeely.
(In reply to comment #107) [...] > The behaviour you describe is called "memory fragmentation" and is > (unfortunately) completely normal. There's no real cure for it. If you know one > that really works, you could be richer than Bill Gates. See bug 276342 for a few > ideas that were useful for me in other projects, but it will never solve the > problem completeely. Just had a look at that other bug, and your ideas look interesting. Maybe the problem will never be solved completely, but IMHO anything that can make it less severe is worth a try. YMMV, but personally I'd rather have FF perform some "memory compression" task every hour than have to kill it myself several times a day. (And if _you_ get richer than Bill Gates in the process, so much the better :-) ).
In the general cases, I would agree with the comment that there's not a lot you can do about heap fragmentation (other than implement a full "locked handle" garbage collection system next time a blue moon comes around). However, in the case of the memory cache, I think this is a specious argument. There *is* something you can do about it, which is to strategically discard enough of the cache to create some free pages and release them (or flush the whole thing if that's too complicated). The only bad effect this would have would be to force those items to disk cache. This, IMNSHO, would be vastly preferable to the current behavior. These cache items aren't irreplacable hand-cut diamonds. There's still no good excuse for the memory cache exceeding it's limits (other than temporarily when the items cached are still displayed on a resident tab... and I might even argue that flushing those to disk could be preferable to leaking memory). But that's another bug...
I do not want to nag, but if the anti-firefox community focuses on this bug, it will inflict serios harm to it's success. See the attachment, FF has swallowed 400MB+ of RAM memory.
I cleared the list of Downloads and after each file Firefox used more memory. In the end when I had deleted all Downloads Firefox was using over 190 K of memory. It didn't free it after I had finished deleting the files. At the moment when I'm writing this Firefox is using 192 K.
Attachment #173606 - Attachment is obsolete: true
Blocks: 213391, 276342
Assignee: jag → dbaron
Target Milestone: --- → mozilla1.8beta2
This bug may have been [partly] fixed recently by bug 283063. D. Baron told me that the fix in bug 283063 may have an impact on the symptoms noticed here in this bug.
Target Milestone: mozilla1.8beta2 → ---
(In reply to comment #112) > This bug may have been [partly] fixed recently by bug 283063. D. Baron told me > that the fix in bug 283063 may have an impact on the symptoms noticed here in > this bug. No I didn't. This bug is about the suite; bug 283063 was for Firefox. I do plan to look at this, though.
Target Milestone: --- → mozilla1.8beta2
This ports a bunch of Firefox leak fixes over, with some variation. (Nulling of _webBrowserFind and focusedElement isn't in Firefox yet, although I'll file a bug on that, and the if (oldBrowser == this.mCurrentBrowser) is handled a bit differently there, although I think this is actually cleaner.)
Attachment #175264 - Flags: superreview?(bzbarsky)
Attachment #175264 - Flags: review?(neil.parkwaycc.co.uk)
This should be pretty harmless, and might improve things a little.
Attachment #175265 - Flags: review?(mconnor)
Attachment #175265 - Flags: review?(mconnor) → review+
Comment on attachment 175264 [details] [diff] [review] port a bunch of firefox leak fixes over sr=bzbarsky, but I'm a little confused as to why this code can get away with not calling updateCurrentBrowser() -- that should reset things like the content-primary shell id, etc...
Attachment #175264 - Flags: superreview?(bzbarsky) → superreview+
(In reply to comment #114) > Created an attachment (id=175264) [edit] > port a bunch of firefox leak fixes over > // This has to hapen before we remove the child so that the s/hapen/happen/... not a big deal, really, I guess. -[Unknown]
Comment on attachment 175264 [details] [diff] [review] port a bunch of firefox leak fixes over >+ <field name="mDestroyed"> >+ false >+ </field> >+ >+ if (this.mDestroyed) >+ return; >+ this.mDestroyed = true; >+ >+ // This has to hapen before we remove the child so that the >+ // XBL implementation of nsIObserver still works. Is it worth porting these bits which don't apply to xpfe? >+ if (oldBrowser == this.mCurrentBrowser) >+ this.mCurrentBrowser = null; >+ > this.mTabContainer.removeChild(oldTab); > this.mPanelContainer.removeChild(oldBrowser); > > // When the current tab is removed select a new tab > // and fire select events on tabpanels and tabs > this.mTabContainer.selectedIndex = newIndex; bz, this line implicitly calls updateCurrentBrowser via the select event. Howver I did wonder why dbaron chose to null out the focusedWindow/Element in the tabbrowser.xml code in the firefox version but in the browser.xml code in the suite version...
Attachment #175264 - Flags: review?(neil.parkwaycc.co.uk) → review+
(In reply to comment #118) > >+ // This has to hapen before we remove the child so that the > >+ // XBL implementation of nsIObserver still works. > Is it worth porting these bits which don't apply to xpfe? Oops, I'll remove that comment. > Howver I did wonder why dbaron chose to null out the focusedWindow/Element in > the tabbrowser.xml code in the firefox version but in the browser.xml code in > the suite version... That's what I was referring to in comment #114: > and the if (oldBrowser == this.mCurrentBrowser) is handled a bit > differently there, although I think this is actually cleaner.)
Above patch checked in 2005-02-23 10:19 -0800. I think most of the issues relating to tabs are now fixed. There were a lot of issues discussed relating to malloc implementations failing to return memory (fragmentation doesn't help), but this bug was specifically about tabs, so those discussions didn't belong here. So, in the spirit of keeping one issue per bug, I'm marking this bug fixed. Other clearly defined and *fixable* issues should be filed as separate bugs.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Resolved or not, with FF v1.0.1. it is still my largest "memory eating" program.
(In reply to comment #121) > Resolved or not, with FF v1.0.1. it is still my largest "memory eating" program. thats cause its fixed on trunk, wait for 1.1
*** Bug 258567 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.8beta2 → ---
Target Milestone: --- → Seamonkey1.0alpha
is this bug considered fixed with firefox or just Mozilla?... Thanks, Chris
this bug is just for mozilla suite. there is a separate bug for firefox. both fixes have been checked in, and will be in the next releases.
(In reply to comment #125) > this bug is just for mozilla suite. there is a separate bug for firefox. both > fixes have been checked in, and will be in the next releases. why are there still so many votes for the bug then? that's why i was getting confused...
presumably many people are still using the current release of the mozilla suite, and thus still experiencing this bug.
No longer blocks: majorbugs
*** Bug 296794 has been marked as a duplicate of this bug. ***
Platform: P4, 1GB RAM OS: W2k SP4 Firefox 1.03 Build 2005041420 Many people are using tabs, i prefer single windows. So most of the time i have 5-20 windows opened. After closing all windows except of one Firefox frees 10% of mem in maximum. Try this: find a website with many gif and flash animations, note the used memory and go have a nice afternoon at the beach. After coming back sometimes you will find a nice "out of memory" requester... This also works even if your PC is not online and just showing the page! I tried almost everything, i disabled the cache completely, i disabled gif animation, i also tried it with 8 Bit colour video resolution - nothing really helped.
Platform: P4, 1GB RAM OS: W2k SP4 Firefox 1.03 Build 2005041420 Many people are using tabs, i prefer single windows. So most of the time i have 5-20 windows opened. After closing all windows except of one Firefox frees 10% of mem in maximum. Try this: find a website with many gif and flash animations, note the used memory and go have a nice afternoon at the beach. After coming back sometimes you will find a nice "out of memory" requester... This also works even if your PC is not online and just showing the page! I tried almost everything, i disabled the cache completely, i disabled gif animation, i also tried it with 8 Bit colour video resolution - nothing really helped.
if you're not using tabs, then this is the wrong bug to post about it in. either find this bug and post there, or file it yourself.
(In reply to comment #131) > if you're not using tabs, then this is the wrong bug to post about it in. > either find this bug and post there, or file it yourself. This memory behaviour of Firefox/Firebird already existed before the tabs had been integrated. And thats what i wanted to show: the reason for this bug are not the tabs...
If turning off GIF animation and the only stressing media on the page are Flash animations, then it's probably the Flash plugin, not Firefox tabs. I'm pretty sure the memory use problems in this bug isn't due to Flash or GIF since the patches that were checked in didn't concern that at all.
*** Bug 311018 has been marked as a duplicate of this bug. ***
*** Bug 316074 has been marked as a duplicate of this bug. ***
Is it sure that this bug is fixed? I still get huge memory consumption even with one tab open. Attaching image as proof!
Image as addition to Comment #136.
One thing you can do is create and set config.trim_on_minimize to true. That will lower the memory usage significantly when you minimize it and then unminimize it. If you do this a couple times, it will get the memory usage down a lot. Now, as for why you can continue to minimize and unminimize with it and get more gains, I think is indicative of either it being an experimental setting, or that there is still buggy memory management involved. Also, though, if you have browsed for a couple hours and then close down to one tab, there will still be contents saved in the memory that inflate the memory usage, compared to if you just opened that current site into a brand new window. So, since we have the ability to clear and even turn off the disk cache and the same goes for history, and we have the ability to disable caching in the memory with browser.cache.memory.enable, maybe we should have "clear history in memory" and "clear cache in memory" buttons in the options. One thing for you to try, try browsing with browser.cache.memory.enable set to false. Then see if you still get the outrageous memory results or "leaks". If you still do, then there is a leak, if you don't, then you need to look for a bug discussing how the memory resource management could be optimized. According to this wiki, your memory use is typical from your screen shot: http://kb.mozillazine.org/Memory_Leak#Memory_usage_upon_minimize And my question for all: Is the back and foward caching that is stored in the memory cache actually being managed and released per tab as this bug is asking for, or is there still some cache being saved for use across tabs? Cross tab memory caching COULD, in theory, optimize browsing when similar pages are being browsed among different tabs, but, it sounds like it would have to be coded with pefection. Hopefully, currently, each tab's back and forward memory cache is being stored individually, as if they were individual windows.
do you know if config.trim_on_minimize also works in linux? amd Mac? does it depends on the WM in use? a few days ago i had firefox with 800Mb of virtual memory in use... that i could only release to usable values when i closed all tabs/windows. :\
The option only works on Windows - it simply asks Windows to manage Firefox's memory slightly differently, and does not actually affect the *allocated* memory at all.
Unfortunately I not an expert, but IMHO we don't have a classical Memoryleak, as the memory _can_ get freed. I'm watching this for quite a while and it looks to me as every thing works the way it schould, but we want it to work differnt. I think the situation now is: If new memory is needed MOZ(FF/TB/SB/whatever) looks if there is something to be thrown out of the cache. If not, it takes new memory. If we have the trim on, everything is thrown out on minimize. What we want (at least I think so): A timer which clears old stuff out of the mem-cache and writes it to the disc-cache. (I'm afraid all the hackers have so much ram they don't care) With WinXP this isn't such a big problem anymore as paging works much better as with W2K, but still imo it's not the way it should be. FF using 77MB just having this page open sucks!
I'm pretty much positive this bug hasn't been fixed. I'm using Firefox 1.5 RC3 and it's very easy to recreate: 1. Go to http://www.gnu.org/software/libc/manual/html_mono/libc.html (this is a huge page and will take time to load and Firefox will become unresponsive while loading). You can save the page locally if you have a slow connection. 2. Check out memory usage. 3. Close the tab and check out memory usage 4. Open a new tab and go the same URL again and check memory usage Each time the page is loaded the memory usage increases until Firefox eventually crashes. Here's the memory usage in my case: 0. Staring usage: Around 40 MB (30 MB Virtual Memory) 1. Loaded URL: Around 140 MB (129 MB VM) 2. Closed tab: Around 117 MB (106 MB VM) - Over 70 MB memory lost at this point 3. Manually clear cache: No chance in memory from #2 4. Open tab and load URL: Around 190 MB (179 MB VM) 5. Closed tab: Around 168 MB (157 MB VM) - Over 130 MB memory lost at this point I stopped at this point, because Firefox crashes if I go much higher than this amount of memory.
I took this after closing the tab in step #5 above. I tried to switch to the about:cache tab, but Firefox became unresponsive and then crashed when I closed it. Enabling the "config.trim_on_minimize" option will lower the actually amount of memory used when Firefox is minimized, but the VM size remains the same at 158 MB. 158 MB is way to high for only having 1 page displayed at this point.
(In reply to comment #142) > I'm pretty much positive this bug hasn't been fixed. I'm using Firefox 1.5 RC3 > and it's very easy to recreate: This bug was about a leak relating to *all* tabbed browsing usage. If you have a leak to report on a specific site, that's a different bug. (Sure, we *could* have a bug report on file called "Firefox has bugs" and mark all bugs duplicates of it. Or we could have 5: "Firefox sometimes crashes", "Firefox sometimes hangs", "Firefox sometimes leaks memory", "Firefox sometimes behaves incorrectly", and "Firefox sometimes has bad user interface". But that's not the point of a bug tracking system. And this bug is not the "Firefox sometimes leaks memory" bug.)
Using the cite in comment #142, I repeated his experiment. I have 1.25GB RAM on a 2.4GHz machine running WinXP Pro SP2. The original tab was at gmail. These are the stats for Firefox usage on Windows Task Manager: Opened site: 159MB; closed site: 129MB Opened site: 163MB; closed site: 133MB Opened site: 165MB; closed site: 136MB Opened site: 164MB; closed site: 138MB Opened site: 165MB; closed site: 138MB Opened site: 165MB; closed gmail by accident: 164MB Using Undo Close Tab, reopened gmail then closed the GNU site: 150MB I did not use minimize to slim down the memory usage, since I don't normally do that.
(In reply to comment #141) > What we want (at least I think so): > A timer which clears old stuff out of the mem-cache and writes it to the > disc-cache. (I'm afraid all the hackers have so much ram they don't care) That would be an excellent complementary feature, especially as we now have the option to sanitize on shutdown. As you describe it, it would just have to be intelligent in its deciding of what is old. But, I still don't think this would fix this bug, because we still have this situation where all the cache of a tab, that does not reference to any other tab, is not being completely released from the memory when the tab is closed.
*totally ashamed* After I deactivated Tabmix it works fine for me. (Sorry for all the Bugspam my stupidity brought you)
Could someone explain how/whether this bug was fixed? I still see the behavior described here in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
It says above that a fix has been checked in. Thanks for that - my browsing laptop only has 256 meg of RAM so FF is quickly using up all available and practically freezing my system. At that point, the windows won't close and I can only manage to use Task Manager to kill ff process. I have tried set that memory cache variable to 5000 as some article recommended but FF uses over 100 meg.
I still have the same problem with Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.7.12) Gecko/20060116 (my system slows down while mozilla takes all the ram it can found, then my system hangs and the only way to get it back working is to turn the power off, then scan the disk... it takes much time, and it's why I nearly don't use mozilla any more :( So I would also like to know how this bug has been fixed
(In reply to comment #149) > It says above that a fix has been checked in. Thanks for that - my browsing > laptop only has 256 meg of RAM so FF is quickly using up all available and > practically freezing my system. At that point, the windows won't close and I > can only manage to use Task Manager to kill ff process. I have tried set that > memory cache variable to 5000 as some article recommended but FF uses over 100 > meg. > I can just hope that any fix there is will someday (hopefully soon) be ported to the Firefox 1.5 Branch which is what I use (currently "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060117 Firefox/1.5", build ID:2006011703, where I still see this behaviour AFAICT). However, dear Carolyn, the pain is slightly alleviated thanks to two extensions: "Tab Mix Plus" (or "Session Saver" which has only part of its functionality, but it's the part about which I'm talking here), which can automagically reload all my tabs from last session (even from a crashed session) when starting up Firefox, and "Restart Firefox", which can unload and reload Firefox at a single click on a toolbar button (plus an "Are you sure" confirmation). Thanks to them, whenever Firefox's bloat is making Windows unbearably slow, I can reclaim several hundreds of megs of virtual memory space cleanly, without the need to kill Firefox by help of taskmgr.exe. Of course, the slower Windows has become, the more patience is needed between the act (clicking on the Restart Firefox button) and the effect (Fx closing down then reopening with the same pages in the same tabs but using up less memory); but in my experience, waiting long enough (up to a few minutes) is all that is needed. (YMMV, as they say; but you just might try it to see if it works for you.) Another solution (not exclusive of the one above) would be to go downtown to your friendly hardware shop (pun intended) and see if they can add some memory to your box (mine has about twice what you have, and I believe it helps some).
(In reply to comment #151) > Another solution (not exclusive > of the one above) would be to go downtown to your friendly hardware shop (pun > intended) and see if they can add some memory to your box (mine has about twice > what you have, and I believe it helps some). You're right I've got another station which got much less problem with this bug 'cause there's 1.5 Go of ram installed ! whith that much You can usually work a whole day without restarting the system...
More RAM to a computer, is not a solution to a memory leak problem from software. You shouldnt have to restart software every hour or at all, its ridiculous. I have Half a GB or RAM and have to restart every couple of hours because I witness in the task manager RAM usage going up for Firefox only, without anything even going on. Firefox is supposed to work better on many machines where other browsers cant, there's huge numbers of browser only type laptops out there with 64MB RAM on Win 98 etc, where is this problem is persisting it would make Firefox near un usable. Tab mix does seem to be a particular issue and connected and I reported that to them on theyre forums with no response. Still theres issues with Firefox that still dont seem to be being addressed, or at least in a remotely transparent way, even though you see it being mentioned in Mozilla meetings minutes.
Can the creator of this bug reopen the issue?!
or anyone with the capabilities, this simply isnt fully resolved.
(In reply to comment #155) > or anyone with the capabilities, this simply isnt fully resolved. Do you have some steps to reproduce the problem?
This bug is not a bug about any memory leaks. It's a bug about the specific problem that all opening and closing of tabs leaked a substantial amount of memory until the window containing those tabs is closed.
one thing its sure, firefox main problem is high ram usage, mozilla people need to find a way to keep it in usable values, having firefox eating almost a 1Gb of ram in a 512Mb system its crazy, specially when konqueror, opera and IE with the sames pages are more usable... one of the main causes for this is the over usage of uncompressed images and over usage of memory cache over disk cache... but please, at least give a choice to solve this problem for those with less than 2Gb of ram
This bug is - obviously - NOT RESOLVED on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2 ! I can't imagine how this bug could get marked RESOLVED/FIXED when firefox is using 200M+ of ram after several hours of browsing; opening and closing many tabs included. Opening and closing many tabs (especially *at once*), as in reading news on http://www.heise.de or browsing picture galleries - in both: going through the index and opening all interesting sub pages into tabs to have a look at them later - causes a very quick increase of memory usage, which does not go down afterwards. Firefox MUST NOT release as 2.0 before this bug is fixed, and all memory leaks are tracked down. Using daily builds on both win32 (NT5.1sp1) and linux32 (2.17.x K7 kernel, running on an amd64 cpu), I can not spot any difference regarding all this leakage. Reopening as 2.0 (moz1.8.1) blocker. (PS: If I had the rights... Someone in charge should do this. So: VOTE: - reopen - target: mozilla 1.8.1 - severity: blocker ) Klaus Bitto
In the bug system you seem to want us to have, we would have about ten bugs: * browser leaks memory * browser sometimes crashes * browser sometimes has bad user interface * browser is too slow * browser sometimes displays pages incorrectly (and a few more) Please file a new bug on the specific problem you're seeing, with *specific* instructions for how anybody can see the bug occur.
Maybe a new keyword would help. Too bad "Bugzilla Bug 309374 Should add "memoryuse" keyword to bugzilla." is marked WONTFIX.
(In reply to comment #161) > Maybe a new keyword would help. Too bad "Bugzilla Bug 309374 > Should add "memoryuse" keyword to bugzilla." is marked WONTFIX. > see also discussion under bug 340082 Maybe this bug should have been marked as INVALID rather than FIXED: it's no use filing a bug if no one can tell whether it's a single problem or many, and if people don't agree on how to tell if it's fixed and on where to look for a fix. Whining won't get anything solved.
It is really hard to narrow this down, especially for a non-developer. The browser is really behaving weirdly, and windows swapping seems to be involved as well. @ #c160: I don't know how it comes that firstly the developers are oblivious to these memory leaks that are simply obvious, and secondly, everyone seems to be too lazy to investigate the problem, especially those who could help. Everyone I'm reading replies like yours, and I have no idea why you aren't simply trying to reproduce the problem. How should *I* (I would use a capitalized "I" here, if it wasn't already one) find out what causes these leaks?? Anyway, as yesterday some dude contacted me by email, asking if this problem is still occuring with all extensions disabled, I tried it, documenting the process. Disclaimer: I'm really sorry that all screenshots are so small and blurry! Please don't hang yourself on that problem. 0) Start firefox. Footprint is around 35M. 1) With all extensions disabled, open http://www.gnu.org/software/libc/manual/html_mono/libc.html 27 times. The strange number is because I had it with extensions 27 times, just because I clicked first and counted afterwards. I wanted to have a base for comparison. 2) Observe ff's footprint in the task manager. It raises up to 749M, which is 28M per tab! http://i78.photobucket.com/albums/j91/preview2/ff-mem-01.jpg 3) When the last 2 or 3 tabs are loading, the footprint jumps up and down wildly, in a range of several hundred M. No idea how this is even possible. Example: 50M, here: http://i78.photobucket.com/albums/j91/preview2/ff-mem-02.jpg 4) When all tabs were loaded, it jumped even down to 16M once, which is far below the normal footprint (like after the browser startup): http://i78.photobucket.com/albums/j91/preview2/ff-mem-04.jpg 5) During all this process, my swap file grew to a size of 1.42G from the normal ~ 350M, as the taskmanager shows: http://i78.photobucket.com/albums/j91/preview2/ff-mem-03.jpg . You can also nicely see the periodic cpu usage. The drawing speed in this graph is 2 seconds per pixel, which is "Normal" in the "View" > "Redraw speed" menu. 6) Now I begun trying to close those tabs. I tried closing several at once by using the mouse wheel, clicking several tabs quickly one after the other, as well as clicking single tabs' close button and and waiting for them to close. In both cases it took very long for firefox to do the requested action. 7) No matter if firefox was in the process of closing one or more tabs, or not, it did not react. Therefore, I do not know when it actually noticed my "close" request and begun closing the tab. As you can see, either in the title bar or with the missing content redraw, firefox does not react: http://i78.photobucket.com/albums/j91/preview2/ff-mem-05.jpg http://i78.photobucket.com/albums/j91/preview2/ff-mem-06.jpg http://i78.photobucket.com/albums/j91/preview2/ff-mem-07.jpg http://i78.photobucket.com/albums/j91/preview2/ff-mem-08.jpg (344 MB, ~ only 5 tabs remaining open!) http://i78.photobucket.com/albums/j91/preview2/ff-mem-09.jpg (360 MB - with a mere of 3 (!) tabs left open!!) 8) Immediately after I had all tabs closed, the footprint was still a ridiculous 194M: http://i78.photobucket.com/albums/j91/preview2/ff-mem-10.jpg 9) 10 minutes later, an enduring, constant 146M: http://i78.photobucket.com/albums/j91/preview2/ff-mem-11.jpg 10) Another 20 minutes later, when I had two open tabs of photobucket and one tab of gmail, both pages not having such a huge DOM tree, the memory footprint was 180 M. (!) If the browser was not leaking memory, it should be around 40M, which is 4.5 times less. Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060909 BonEcho/2.0b2 And don't you even dare to tell me to try it in the current nightly! NOW, I think, I can really demand to see this fixed, and to see it blocking FF2.0. Remember that not everyone has 1G RAM and 1.5G swap available. Btw., in the first picture (http://i78.photobucket.com/albums/j91/preview2/ff-mem-01.jpg) you can see Windows telling me I had little space on my HD free - I'm having, with my current swap, 369M of 12,7G free. During the closing of tabs, Windows told me it had to resize the swap file. All for firefox to hog more memory. Currently, after surfing for like 10 minutes, without much usage of tabs (I have opened and closed around 5 tabs), and then beginning to write this bug comment, Firefox is using 84,580K. I'm having 2 tabs open: This bug thread and gmail. Isn't it ridiculous? Yeah, now you go tell me this bug is fixed. I love you too.
Don't see anyone whining here. Just frustrated people who are told time and again that the memory leak(s) are sorted, only to find they aren't. Firefox will only get to be a great browser when the collective developers stop being in denial about this critical issue and sort it. Reproducing the problem is easy - just use FF for a length of time, open a number of tabs, watch the memory skyrocket over 150 - 200 Mb, and then start closing tabs and watch in horror as the memory doesn't drop back. It can take a few hours for the accumulation to happen, granted, but I have yet to see another piece of software do this. I'm going to try a nightly build, just to prove it, but I'm not holding my breathe on this.
Just wanted to note that this Bug ist a Seamonkey not a Firefox-Bug. So either it should be moved to Core or a new Bug should be opened for FF.
But it should still block the target milestone of Firefox 2.0, shouldn't it?
Well the Bug (Problem) should. But not Bug 131456. This is why this bug will stay RESOLVED FIXED. Please check if there is a appropriate bug for FF and if not file one and make a Link to this one. Or the Produkt should be changed to FF and the bug reopend. I'm not able to do this, as I don't have the rights to do so.
This should have been in Firefox anyway, but when i opened this bug a freaking 4 and a half years ago, Firefox didn't exist. I am reopening this just so people stop sending emails requesting the reopening of this bug. So, reopening and changing the product.
Status: RESOLVED → REOPENED
Component: XP Apps → General
Flags: review+
Flags: blocking1.8a1-
Flags: blocking1.7-
Flags: blocking1.4a-
Product: Mozilla Application Suite → Firefox
Resolution: FIXED → ---
Target Milestone: seamonkey1.0alpha → ---
Version: Trunk → unspecified
(In reply to comment #164) > Reproducing the problem is easy - just use FF for a length of time, open a > number of tabs, watch the memory skyrocket over 150 - 200 Mb, and then start > closing tabs and watch in horror as the memory doesn't drop back. It can take a > few hours for the accumulation to happen, granted, but I have yet to see > another piece of software do this. That sounds like bug 130157. This bug is about memory use continuing to rise (a memory leak), not about memory use not going down (failure to release memory back to the OS). Do you have a set of reproducible steps that shows memory usage increasing without limit when tabs are opened and closed?
(In reply to comment #169) > (In reply to comment #164) > > > Reproducing the problem is easy - just use FF for a length of time, open a > > number of tabs, watch the memory skyrocket over 150 - 200 Mb, and then start > > closing tabs and watch in horror as the memory doesn't drop back. It can take a > > few hours for the accumulation to happen, granted, but I have yet to see > > another piece of software do this. > > That sounds like bug 130157. This bug is about memory use continuing to rise (a > memory leak), not about memory use not going down (failure to release memory > back to the OS). Do you have a set of reproducible steps that shows memory > usage increasing without limit when tabs are opened and closed? > Not specifically, but I wouldn't know the difference anyway, I have to say. Right now, I have FF sat on just over 77Mb of memory, with five tabs open, and that's after about 2 hours with some activity in each tab, but its been at rest for the last hour, minimised. The nearest app, memory use-wise is taking about a third of that. Now, if I kill one tab (single click on its 'x'), FF drops about 600Kb. Close another, using right-click>close, probably about the same, but we're still hoving around 77Mb. If I leave these in place until tomorrow, it will have crept up a fair bit. However, I'm going to try the nightly build for a day or two and see if that make any difference.
I just tested Comment #163 test case and I don't seem to be able to reproduce, Perhaps try the test case with a new profile ( -profilemanager ) and in safe mode ( -safe-mode )? To see if it's setting related.
Running the Browser Mem Buster Test testcase attached, Firefox 3 trunk 9/11/06 nightly build, SeaMonkey 1.1 branch 9/11/06 nightly build, and Opera 9.01, I get the following results with Windows XP SP 2: After test After closing tabs Firefox 98 MB 84 MB SeaMonkey 96 MB 86 MB Opera 129 MB 121 MB It doesn't seem that Firefox or SeaMonkey have any problem with releasing memory when tabs are closed. Note that the test itself opens and closes tabs, and I also closed tabs after the test was done. Not all the memory can be released to the OS due to memory fragmentation and memory stored in caches, so the fact that memory use did not return to the use before the test is not indicative of a problem. I can try to create a longer version of the test that opens the Alexa top 100 US sites ten times each to see if that demonstrates a very subtle problem that takes longer to notice. Note: In Opera, allowing popups from bugzilla.mozilla.org is fairly tedious: In Tools -> Preferences, go to the Advanced tab and click on Content. Click the Manage site preferences... button. Click the Add... button and add the site bugzilla.mozilla.org. Under Pop-ups, select Open all pop-ups.
You don't even have to open any tab to get Firefox exhaust your computer memory and processor usage : just load this image : http://facs.scripps.edu/surf/images/euranim.gif I already mentionned this problem in #306680 and #332463 but developpers obstinate to keep the bug as Fixed :( Perhaps Firefox developpers should have a look to the original Mozilla code, as there were many more functionnalities, less bugs and much less memory usage with mozilla.
(In reply to comment #163) > Isn't it ridiculous? Not really. Opera 9.01 behaved similarly, consuming 1389 MB when the 27 tabs were opened, and 40 MB after they were all closed. The Firefox 3 9/11/06 nightly build consumed 1193 MB when the 27 tabs were opened, and 102 MB after they were all closed. Firefox's memory use was greater than Opera's after closing the tabs, but still within a normal range of memory use (see Browser Mem Buster Test results) and the extra memory is likely just due to memory fragmentation. If that testcase causes Firefox to actually leak memory (as determined by some sort of memory leak tool or by causing memory use to rise without limit), please file a separate bug report on it.
OK. Look. This bug, as filed, was RESOLVED FIXED. There were leaks. This bug has a patch that fixed them. If there are also OTHER leaks, there should be OTHER bugs covering them. Bugs which don't have ~200 comments worth of unrelated back-and-forth to cloud the issues. I'm reresolving this bug. Please do not reopen it -- doing so is an abuse of the bug system and doing so repeatedly will get your bugzilla privileges revoked. If there is still an issue with memory not being released, please file a new bug with something resembling steps to reproduce (at the very least, the steps you used to determine that memory is not being released). File one bug per reasonably different set of steps to reproduce, since they could very well correspond to different leaks. Please feel free to cc me and David on these new bugs. Again, we're not saying there are no leaks. You guys say you see leaks; we trust you. We need a way to see the leaks ourselves so we can fix them; adding comments to this bug is NOT the way to get that to happen, because no one, and I mean no one, will ever read all the comments on this bug...
Status: REOPENED → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → FIXED
@ #177 (Boris Zbarsky) Are there no memory leaks for *you*?
There are. I file bugs on them as I go, then generally try to fix them. Feel free to query bugzilla for memory leak bugs I filed. Most of the leaks I've seen recently were in the X server, as far as I can tell. But then again, I don't use tabs very much. So I doubt I'd see tab-related leaks (of the sort people are describing in this bug) in my daily browsing.
> Are there no memory leaks for *you*? Just for those who can't believe that others aren't seeing any or many memory leaks: I'm writing this in FF 1.5.0.6 which has been running without restart since this laptop has been booted. Uptime: 16 days and 6 hours (Suspended during the night). That's with intensive daily surfing and sometimes aproximately 200 tabs open. So yes: It's important to give detailled steps on how to reproduce a memory leak. And yes: Sometimes it's difficult to know when something is a memory leak because memory release often doesn't occur the very moment a user takes action.
It's also important to know which extensions people use, since some extensions in the past have caused major leaks. This bug should R.I.P. File new bugs for new symptoms, with reproduce-by steps, as bz said. /be
#163 is a perfect test case. please notice that this libc page is mostly text. i get the same behiavour : memory never released, memory usave skyrocketting, never going down, always increasing over time.
(In reply to comment #164) > Reproducing the problem is easy - just use FF for a length of time, open a > number of tabs, watch the memory skyrocket over 150 - 200 Mb, and then start > closing tabs and watch in horror as the memory doesn't drop back. Depending on what measurement of memory usage you're looking at, this isn't necessarily a bug. Calling free() causes memory to be returned to the malloc heap, but that won't necessarily cause the page to be unmapped. If you want to measure leaks by looking at application memory usage, you're better off comparing peak-to-peak rather than trough-to-trough. In other words, open a large number of tabs, examine memory usage, close them, open them again, and examine memory usage again. However, also note that the numbers the Windows task manager shows for memory usage are really strange -- it's essentially a measure of resident memory that only marks pages non-resident when you minimize the window (depending on the trim_on_minimize pref, since we have the ability to disable that). It would be significantly more interesting to look at total memory mapped or at a more useful measure of resident set.
Product: Firefox → Mozilla Application Suite
Component: General → XP Apps
this is not windows specific. it happens on linux too. i understand that free may no return the memory to the system, but memory usage keeps increasing. It's either a leak or heavy memory fragmentation. In both cases, it's a bad behaviour that brings system out of memory.
> #163 is a perfect test case. I can't tell what part of that comment is actual steps to reproduce and which is just griping and complaining by someone not familiar with the way the bug system works. If you can disentangle those parts, please file a bug on it with just the steps to reproduce and cc me. I'll investigate. Thanks in advance!
(In reply to comment #183) > (In reply to comment #164) > > Reproducing the problem is easy - just use FF for a length of time, open a > > number of tabs, watch the memory skyrocket over 150 - 200 Mb, and then start > > closing tabs and watch in horror as the memory doesn't drop back. > > Depending on what measurement of memory usage you're looking at, this isn't > necessarily a bug. Calling free() causes memory to be returned to the malloc > heap, but that won't necessarily cause the page to be unmapped. > > If you want to measure leaks by looking at application memory usage, you're > better off comparing peak-to-peak rather than trough-to-trough. In other > words, open a large number of tabs, examine memory usage, close them, open them > again, and examine memory usage again. > > However, also note that the numbers the Windows task manager shows for memory > usage are really strange -- it's essentially a measure of resident memory that > only marks pages non-resident when you minimize the window (depending on the > trim_on_minimize pref, since we have the ability to disable that). It would be > significantly more interesting to look at total memory mapped or at a more > useful measure of resident set. > more than happy to check some different values within TM, if I know which one(s) to use! Give us some clear pointers and you'll get the numbers back. ;)
(In reply to comment #181) > It's also important to know which extensions people use, since some extensions > in the past have caused major leaks. > > This bug should R.I.P. File new bugs for new symptoms, with reproduce-by > steps, as bz said. > > /be > (In reply to comment #177) > OK. Look. This bug, as filed, was RESOLVED FIXED. There were leaks. This > bug has a patch that fixed them. > > If there are also OTHER leaks, there should be OTHER bugs covering them. Bugs > which don't have ~200 comments worth of unrelated back-and-forth to cloud the > issues. > > I'm reresolving this bug. Please do not reopen it -- doing so is an abuse of > the bug system and doing so repeatedly will get your bugzilla privileges > revoked. If there is still an issue with memory not being released, please > file a new bug with something resembling steps to reproduce (at the very least, > the steps you used to determine that memory is not being released). File one > bug per reasonably different set of steps to reproduce, since they could very > well correspond to different leaks. Please feel free to cc me and David on > these new bugs. > > Again, we're not saying there are no leaks. You guys say you see leaks; we > trust you. We need a way to see the leaks ourselves so we can fix them; adding > comments to this bug is NOT the way to get that to happen, because no one, and > I mean no one, will ever read all the comments on this bug... > I'd do this if I believed that anyone took notice! the last couple of times I've tried to report in this way, the bug filed is promply marked as a copy of some other bug, which in turn doesn't then get fixed. Seriously, there is a feeling that there is a collective denial of these memory issues, since the past two releases have made loud noises about fixes to leaks etc, any yet we see the same issue come straight back around the corner!
(In reply to comment #187) > I'd do this if I believed that anyone took notice! > the last couple of times I've tried to report in this way, the bug filed is > promply marked as a copy of some other bug, which in turn doesn't then get > fixed. > Seriously, there is a feeling that there is a collective denial of these > memory issues, since the past two releases have made loud noises about fixes to > leaks etc, any yet we see the same issue come straight back around the corner! You've filed one bug, bug 308572, which doesn't contain any information about why you see leaks and others don't, such as what pages you visited, what functions of the browser you used, what extensions you have installed, etc. In other words, bug 308572 is no more useful than one of the bugs described in comment 160. More specific steps to reproduce are required for a bug to be fixed.
nearly VERIFIED with Windows NT 5.1; en-US; rv:1.9.1.5pre) Gecko/20091019 but this bug report needs to get off the duplicates list.
Status: RESOLVED → VERIFIED
Date: 2016-2-17 I use Ubuntu 14.04.3 and have a live indicator (system load indicator) that displays my cache memory and other resources. What it demonstrates is as pages or tabs are open (seem about the same) memory consumption is steady at about 1.9GB total RAM (system and everything else). While cache memory starts at today 1.5GB with five desktops and 5 browser instances, of 12 desktops (Ubuntu can have as many desktops as your memory can support, try that windows!), during the day, after close and opening new pages the cache will go up to maximum and never go back down. Killing the PID or kill firefox.bin never returns the cache memory. The only way I can recover allocated cache is to reboot. My motherboard supports only 8GB of RAM and 4 Core (AMD Phenom 9750 Quad-Core Processor × 4). The Graphic card also supplies it's own RAM for video at 512MB (GeForce 8500 GT/PCIe/SSE2), currently set at 256MB aperture (512+256=768 RAM), that Firefox seems not to know about? So for years now this condition has existed and Fire Fax ignores the problem!!! All I ever get is that it must be the Add-Ons? Well this is just NOT TRUE as the same exist without any Add-Ons or restart with Add-Ons disabled! Further the Add-Ons I use are not a convenience but a necessity for my Web Site Development. Chrome and Opera does not seem to have the same problem as Fire Fox. Unfortunately there Add-Ons are not as far along as it is with Fire Fox. So I ask, Who's butt do I need to put a fire under to get this addressed? How do we get Fire Fox to stop ignoring this problem? I know even with my limited understanding with programming in Visual Basic, C++, Java, PHP, and COBAL that Fire fox does know it's shut down state as the restore function would not work on reboot or reload when Fire Fox crashes (a bi-weekly event and almost daily in XP). BTW Fire Fox is very fast in Linux compared to anything Windoze. My page load is 0.078/s in Linux and 1.43/s in XP or Vista or 7, 8 and 10. But then I can control the eye candy in Ubuntu much easier! Data: Fire Fox 44.0.2 for Ubuntu Ubuntu (Linux) 14.04.3 LTS (14.04) Ubuntu, with Linux 3.19.0-49-generic or pae Memory: 7.8 GiB Processor: AMD Phenom 9750 Quad-Core Processor × 4 Graphics: GeForce 8500 GT/PCIe/SSE2 OS type: 64-bit Disk Partition: 537.4 GB of 1.5TB WD Black James Niland nilandsplace.com
(In reply to James Niland from comment #190) > Date: 2016-2-17 > during the day, after close and opening new pages the cache > will go up to maximum and never go back down. Killing the PID or kill > firefox.bin never returns the cache memory. That's how cache memory (disk cache) on Linux works. It's effectively free memory that the kernel is using for disk cache (instead of having the free memory sit idle). If you really want to lower it: sync; echo 3 | sudo tee /proc/sys/vm/drop_caches ought to do a pretty good job of freeing it without rebooting.
I am also having this problem. FF will use almost 2 gigs of RAM, no idea how much disk cache it is also using, but it uses way more than what I remember from the past. Same situation, opening many tabs over the course of the day, especially sites like Facebook and YouTube seem to use some serious memory, around 700+MB sometimes more. I don't know if the web is just getting too loaded with junk and requiring a ton more memory than before, but it's causing massive performance issues for me. It's almost as if FF is continually loading everything into memory and not letting it go, so it just increases constantly until it's using so much that it literally slows down my entire system and the browser usually crashes. I find though if I close FF and restart it the memory is then cleared, but again it creeps up quickly. I agree that FF developers should take a closer look at memory management and introduce a more aggressive cache clearing method of some kind. Anyway, I have the latest FF. I have 16gigs DDR3 1600, 6 core AMD processor at 3.2-3.9ghz, half gig storage on raid 0 and 4gigs ddr5 of video memory using a geforce gtx 1050Ti video card. All hooked into an ASUS tough mother board, 990FX. If you have any questions let me know.
@jeremy first is the normal advice: start firefox in safe mode (without the add-on) and check if you have the same problem. Some add-on have memory leaks second, use the about:memory to check how the ram is being used and if it is increasing with time finally, press "free memory" buttons and check if ram is being released. There is also a add-on named "task manager", that can list the cpu and ram usage of each tab, that may also help identify heavy pages (never ending pages like facebook, twitter may eat lot of memory if you keep scrolling)
Sorry, this is offtopic, but just to make clear 3 thing, so other people here do not think that the @james comment is correct: 1- Never said that firefox do not have any problems, but most problems where fixed and known ones are small. To find if it is a unknown problem, one needs to remove external influences, so add-on and plugins. 2- firefox add-on have too much access to firefox code and can leak memory easily, that is why it is the first one to be blamed. This is one of the reasons that add-on will all be rebuild and use the a new api, mostly compatible with chrome and opera api: https://wiki.mozilla.org/WebExtensions . Leaking memory with it will be harder. 3- sysctl -w vm.drop_caches=3 is stupid, you drop caches and then the system will need again the info, will stall, read it and cache it back, only increasing IO and CPU usage in the end for a useless temporary memory release. This is only useful for testing/debugging or after "one time" massive IO operation on many files, that do not need to be kept in cache, but even that, the kernel will free it if they are not used after some time. Read the kernel docs if you do not believe me: https://www.kernel.org/doc/Documentation/sysctl/vm.txt If memory is unused, using it for cache is a good thing. If the system needs memory, the kernel release old cache and use the free memory If someone want to reply, reply directly to my email.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: