Closed Bug 250558 Opened 21 years ago Closed 21 years ago

Firefox not respecting maximum Memory cache size

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: silverbacknet, Assigned: bugzilla)

Details

(Whiteboard: bug #131456 - Suite version of this bug)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefoxy/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefoxy/0.8 I have my memory cache set to 512 k, and sometimes up to 4096 k for working. My current memory cache usage is 21 MB, according to about:cache, and accordingly the total program memory usage is about 50 MB. I know the two are related, as when one grows the other does. It is a bug to treat the limit as a suggestion only. Reproducible: Always Steps to Reproduce: 1. Set memory cache size to 512. 2. Browse a few minutes. 3. Check about:cache. Actual Results: Memory cache device Number of entries: 146 Maximum storage size: 512 k Storage in use: 21188 k Inactive Storage: 0 k Expected Results: Memory cache device Number of entries: 6 Maximum storage size: 512 k Storage in use: 488 k Inactive Storage: 0 k Firefox 0.8, may not remain in .9 but since I can't run it I can't check. Didn't find any mention in Bugzilla.
I just did a search for bugs like this, and I found a couple of bugs that sound similar: bug 75401 and bug 181668 I wont mark this as a duplicate because those are from a couple years ago and something could easily have changed since then. However, the build you are using is rather old. You might want to go to http://www.mozilla.org/releases/nightly.html and get a newer build and then try to reproduce this bug. Please report back.
I almost missed this, in regards to not being able to run Firefox 0.9, try using a new profile and make sure you install it into an empty directory. A lot of problems are the result of installing a newer version over an old version.
Note that you can temporarily use more than your memory cache, if you're displaying a page with a few large objects. Tabs can make this even more complicated. And your 512K cache is really too small, you'll often go above the limit ! Ofcourse, 21MB is another matter.
Actually, that was the first thing I did when I upgraded to 0.9.1, I guess it just didn't like my system. But I got the latest trunk nightly and it seems to work quite well, aside from loading XPIs. Anyway, I've run some more stress tests on the browser, and I can tell the code has been improved quite a bit, but still isn't quite right. It still doesn't throw out all the images required to move the memory cache below the limit when a page is clicked out or tab closed. I ran it on a few cache sizes from 512 to 4096, and always once I hit the max it would steadily creep up. (I did move mine back to 4096, which is more sane.) Not as bad as before, though, so I'm marking this as minor until someone decides what to do with it.
Severity: normal → minor
Based on number of similar bugs for "trunk", bug #213391, bug #51028, and dups, confirming this Firefox version.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can confirm. Considering how many people are complaining about memory problems, this should have a high priority. Easily duplicated, I think. Just go to images.google.com and search for dogs. Open a few tabs. Memory cache device Number of entries: 284 Maximum storage size: 18432 KiB [default value] Storage in use: 30247 KiB Inactive storage: 0 KiB [FF 1.0, Win XP Professional SP1, 384 MB]
AFAICT, cache memory for picture files (*.jpg et al.) is never released as long as Firefox is running. See my attachments and comments to bug 131456 for examples. Best regards, Tony.
(In reply to comment #7) > AFAICT, cache memory for picture files (*.jpg et al.) is never released as long > as Firefox is running. That's another bug, but in any case, on my system it retains anything that does not exceed the maximum storage size (memory cache limit). Anything above the limit it releases. Doesn't matter whether it's JPEGs or what. Sorry, just version 1.0, not the latest release.
(In reply to comment #8) > (In reply to comment #7) > > AFAICT, cache memory for picture files (*.jpg et al.) is never released as long > > as Firefox is running. > > That's another bug, but in any case, on my system it retains anything that does > not exceed the maximum storage size (memory cache limit). Anything above the > limit it releases. Doesn't matter whether it's JPEGs or what. Sorry, just > version 1.0, not the latest release. Did you look at the recent comments for that other bug? You'll see some examples where the "maximum" for memory cache is exceeded by 1000 or 2000% (yes, ten or twenty times), while the maximum for disk cache isn't; and reducing the load (closing tabs, for instance) does not release any of that elephantine excess baggage. Best regards, Tony.
I'M NOT AT ALL CONVINCED THAT THIS IS A BUG. As I explain below, I think the "Maximum storage size" field in about:cache is just mislabeled a little, and that's causing a big misunderstanding among users. In my tests the FF Memory Cache Device storage size is as large as necessary to hold all images in open tabs, and that's the way it needs to be. Some of that memory can be held in swap space (I have loaded it up to over the amount of physical memory without a problem). I also find that the memory in the FF Memory Cache Device (about:cache) is deallocated immediately as tabs are closed, except that it retains up to the "Maximum storage size". Note that sometimes a tab has nothing stored in the FF Memory Cache Device (it seems to store only images, not text). In this case, of course, no memory can be deallocated. If your findings are contrary to mine, please read this paragraph carefully and repeat the test. I suggest that the "Maximum storage size" could be more accurately called the "Maximum storage retained". The way it is now, well-meaning people are going ballistic when they see the "maximum storage size" exceeded, and they assume it's a huge bug that destroys life on earth and demonstrates the incompetence of FF programmers. Recommendation: Rename the "Maximum storage size" field in about:cache and about:cache?device=memory , and mark "bug" as FIXED.
(In reply to comment #10) > I'M NOT AT ALL CONVINCED THAT THIS IS A BUG. As I explain below, I think the > "Maximum storage size" field in about:cache is just mislabeled a little, and > that's causing a big misunderstanding among users. > > In my tests the FF Memory Cache Device storage size is as large as necessary to > hold all images in open tabs, and that's the way it needs to be. Some of that > memory can be held in swap space (I have loaded it up to over the amount of > physical memory without a problem). > > I also find that the memory in the FF Memory Cache Device (about:cache) is > deallocated immediately as tabs are closed, except that it retains up to the > "Maximum storage size". Note that sometimes a tab has nothing stored in the FF > Memory Cache Device (it seems to store only images, not text). In this case, of > course, no memory can be deallocated. If your findings are contrary to mine, > please read this paragraph carefully and repeat the test. > > I suggest that the "Maximum storage size" could be more accurately called the > "Maximum storage retained". The way it is now, well-meaning people are going > ballistic when they see the "maximum storage size" exceeded, and they assume > it's a huge bug that destroys life on earth and demonstrates the incompetence of > FF programmers. > > Recommendation: Rename the "Maximum storage size" field in about:cache and > about:cache?device=memory , and mark "bug" as FIXED. My findings are indeed contrary to yours, and, to use your style of language, I AM SINCERELY, DEEPLY AND FULLY CONVINCED THAT THERE IS A BUG. Here is what _I_ see: In the course of normal browsing, the size of the used swapfile increases very slowly but steadily over the days, and sometimes over the hours. Sooner or later a point is reached where Windows starts using the majority of its time swapping memory to and fro, and at that point strange things start to happen: clicking a button causes the concerned program to lose focus; Firefox and Thunderbird become "not responding" and see their icon (at top left of the program window) replaced by the "default program" icon (a white square with a blue border) for several seconds at a time; the mouse freezes totally for several seconds at a time; if the taskbar option "Group similar icons" was selected, then Firefox becomes one of the subwindows of the "Windows Explorer" taskbar item; and more. Closing tabs reclaims _no_ memory in that case -- in my experience. OTOH, if /instead/ of closing individual tabs I close the whole of Firefox completely and then immediately reopen it _with_ _the_ _same_ _contents_ _in_ _all_ _the_ _tabs_ (thanks to Session Saver), _that_ immediately reclaims a huge lot of memory, up to several hundred megs in just the necessary time to close and reopen -- let's say a few minutes at the most; and the system becomes lively again -- for a few more hours or days.
(In reply to comment #11) I think we're zeroing in on the problem. To keep the noise down, let's continue the discussion off list and report back. Please check your In box. Thanks.
I believe this bug should be closed, not by marking it resolved mind you, but by marking it as being a duplicate of bug 131456 -- or maybe vice-versa. Can anyone with bug-labeling privileges check these two bugs against each other and confirm or infirm my impression?
The two bugs are very similar. However, one is for Firefox and one is for the Suite. Thus, they should be seperate.
Whiteboard: bug #131456 - Suite version of this bug
(In reply to comment #14) > The two bugs are very similar. However, one is for Firefox and one is for the > Suite. Thus, they should be seperate. In that case, maybe the other bug's attachments (all of which actually concern Firefox) should be moved to here. Unless of course the bug can be shown to affect a common component of both FF and Moz-Suite.
Images are kept expanded in the Memory Cache, so they're often 200K or 500K large. Could it be that the check for Max Memory Cache is done when they're still compressed, but when they're actually stored, they are already expanded ?
New record with Mozilla/5.0 (X11; U; Linux ppc; fr; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2) I was browsing a nasty webpage. I closed the tab, and after 2 minutes, about:cache was still Number of entries: 709 Maximum storage size: 21504 KiB Storage in use: 203095 KiB Inactive storage: 0 KiB I can reproduce it with this ugly webpage BE CAREFUL : you need about 200MB of FREE memory to load this page http://home2.scarlet.be/simoen01/page_deb.htm About 5minutes later, some cache cleanup has been done Number of entries: 700 Maximum storage size: 21504 KiB Storage in use: 39051 KiB Inactive storage: 0 KiB meaning that these big images have been pruned.
Unfortunately, this is not entirely reproducible, but it's real. At the risk of redundancy, let me attempt to summarize. I argue that the usual(?) behavior, as described in comment 10, is NOT A BUG, but is reasonable and expected behavior. Unfortunately, failing to release cache after the tab is closed, as described in comment 17, most definitely is a bug. This is closely related to bug 277492 (see comments 1 and 6 from that bug).
I hate to keep piling on evididence, but this is convincing. Duplicating the test in comment 17, here are my results after opening and closing that Web page: Memory cache device Number of entries: 73 Maximum storage size: 18432 KiB Storage in use: 165215 KiB Inactive storage: 0 KiB =========================== Open another 5 images from disk: Number of entries: 78 Maximum storage size: 18432 KiB Storage in use: 210792 KiB Inactive storage: 0 KiB =========================== After closing the 5 images: Number of entries: 73 Maximum storage size: 18432 KiB (default) Storage in use: 165215 KiB (same as before closing) Inactive storage: 0 KiB Results: Not a single byte from that fish page was removed from the cache, no matter how long I waied. Smaller images loaded susequently were removed immediately on closing the tabs.
OK. As filed, this bug is invalid. The memory cache holds all images that are currently being actively used. We could "evict" them from the cache (not list them in about:cache), but they're being used, so we have to store them in memory _somewhere_. Please file separate bugs, one per site, on cases when images are not removed from cache once they are no longer being used (that is, once the image nodes involved have been destroyed).
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
why have you closed ? we all experience everyday major leaks with mozilla browsers. the longer we use firefox, the more it leaks. A firefox using more than 100MB of res memory is quite unusable.
I closed the bug because there are multiple, likely unrelated issues reported here, and because the _original_ issue is invalid. If you want a problem to be looked at, please file a bug on it. One bug per problem. Don't hijack other bugs for your problem. That just makes the bugs completely unreadable and impossible to work with.
He's not closing consideration of memory problems. There are several closely related bugs that are being acted on, but this one doesn't seem to be accurately describe the actual bug(s). The comments in here are still visible and are being taken seriously, however.
The issues are being taken seriously. The comments in this bug are pretty much being ignored, but that was true before I closed it too. In fact, that's the precise reason I closed it -- useful data was being lost in the noise. Hopefully people will file clear bugs with said useful data.
You need to log in before you can comment on or make changes to this bug.