Closed
Bug 277492
Opened 20 years ago
Closed 19 years ago
Closing an inactive tab doesn't immediately make its active memory cache storage inactive
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: schapel, Assigned: darin.moz)
References
Details
(Keywords: perf)
Reproducable: Always Steps to Reproduce: 1. Set browser.cache.memory.capacity to 4096 2. Open a new tab and go to about:cache 3. Open another new tab and go to http://www.google.com/imghp?hl=en&tab=wi&q= 4. Do a Google image search for "cats" 5. Scroll down the page, right click on the Next link, and select Open Link in New Tab 6. Repeat step 5 until you have 20 open tabs with images of cats (meow!) 7. Make the about:cache tab active and reload the page, noting memory cache usage 8. Right-click on the about:cache tab and select Close Other Tabs 9. Reload about:cache tab noting memory usage Expected Results: When I close the tabs I opened, the memory cache they are using becomes inactive. Actual Results: When I close the tabs I opened, the memory cache they are using stays active until the window is closed. When I follow the above steps with Mozilla 1.8a5 and Mozilla trunk build 2005010711 on Windows XP, I get 15-16 MB memory cache usage when 20 tabs of cats are open. After closing all 20 tabs, the memory usage hardly goes down at all. The same happens if I close the tabs without making them active in some other way, such as right-clicking each tab and selecting Close Tab. But if I make each tab active before I close it, the memory is released as soon as the tab is closed. Finally, no matter how I close the tabs, the memory is released when I close the window the tabs were in. It seems that for some reason, cache memory is not immediately released for inactive tabs that get closed. This bug can appear serious to some people because it can look like a memory leak to those who often close inactive tabs and never open or close windows.
Comment 1•20 years ago
|
||
I can confirm and add a workaround and other pertinent information. This may be a crucial bug. I suggest upgrading the severity. Confirmed with FF 1.0, Win XP SP1. A more accurate description would be that the memory storage size remains above the maximum storage size, after the tabs are closed with the "Close other tabs" menu item. After running the Steps to Reproduce, it is possible to increase memory use further. If new tabs are opened again with other images (open a new tab for each cat, until you have >50000 kB Storage In Use), when these tabs are closed the storage will have grown even higher. However, the bug does not appear if the tabs are closed individually, either with the "Close Tab" menu item or with the center mouse wheel. As far as I know, it only occurs if the "Close Other Tabs" menu item. Workaround: 1. Reset the browser.cache.memory.capacity (resets to default value). 2. Close FF and reopen. Problem solved, I think, although I cannot test all possible cases. Anecdotal reports suggest that this may be a serious problem. One user with a serious problem, reported to me that the FF memory use was greatly reduced and FF was much better behaved after he disabled the memory cache and reset the disk cache capacity to 500000 kB. Other users have also reported deactivating the memory cache (browser.cache.memory.enable = false) as a workaround for vaguely defined increase in memory use. Steve Chapel is correct that this appears to users to be a memory leak. (See comment 10, bug 250558.) There is some possibility that it is not just alarming to users, but is the actual source of a very troublesome long-term increase in memory usage.
Reporter | ||
Comment 2•20 years ago
|
||
(In reply to comment #1) > However, the bug does not appear if the tabs are closed individually, either > with the "Close Tab" menu item or with the center mouse wheel. As far as I > know, it only occurs if the "Close Other Tabs" menu item. Are you sure you're closing a tab other than the one that's currently visible? Even if I close an inactive tab with the Close Tab menu item or by middle-clicking, the active memory cache items for that tab are not made inactive. At least that's what I see with Mozilla 1.8a6. I'm adding the perf keyword because having the memory cache full of items that shouldn't be there will decrease the memory cache hit rate and thus slow down browsing. Fixing this bug should make the Back button faster and reduce memory consumption, at least for some users.
Keywords: perf
Comment 3•20 years ago
|
||
(In reply to comment #2) > Are you sure you're closing a tab other than the one that's currently visible? Yes, I'm sure. I just double-checked. We seem to get different results on this one detail. I don't know if it's due to a difference in configuration or a difference in releases. Otherwise, I can duplicate the behavior completely. I would be interested in someone replicating the workaround.
Comment 4•20 years ago
|
||
I can confirm this bug with Win2k and Mozilla1.8a6. Results for "Close other tables" Storage in use Task Manager[Mem Usage - VM Size] 1 tab about:cache 2,080 20,120 12,120 20 cat tabs open 14,054 43,588 34,832 after closing tabs 13,422 41,456 32,684 Results for 1. activate each tab 2. "Close Tab" Storage in use Task Manager[Mem Usage - VM Size] 1 tab about:cache 2,080 19,544 11,620 20 cat tabs open 14,046 43,288 34,832 after closing tabs 3,741 30,752 22,092 We need a more simplified testcase. What exactly causes the leak... lots of images on a page or lots of tabs or some combination.
Comment 5•20 years ago
|
||
(In reply to comment #4) > We need a more simplified testcase. What exactly causes the leak... lots of > images on a page or lots of tabs or some combination. Sufficient cache memory in use will do it. For example, a quick way to confirm it is to open each cat in a separate tab instead of lots of images on each page (i.e., <Ctrl>click on each cat on the Google pages. The actual behavior is complicated. If you do not have sufficient cache in use, you may find that closing the tabs does release cache to below the set maximum. If you close and reopen FF after resetting the maximum, you may find still different behavior. At one point, it incorrecty displayed a maximum size of 0 (a different bug??), which was quickly corrected by cosmic forces. (Don't ask me to reproduce it.) Just play with it and you will come up with lots of test cases. The test case posted is about as simple and reproducible as they come. I think the fact that the behavior is corrected if the maximum size is set to default is highly significant.
Comment 6•20 years ago
|
||
(In reply to comment #1) Unfortunately, the information in this comment has not proven accurate in the long run. > However, the bug does not appear if the tabs are closed individually, either > with the "Close Tab" menu item or with the center mouse wheel. As far as I > know, it only occurs if the "Close Other Tabs" menu item. > Workaround: > 1. Reset the browser.cache.memory.capacity (resets to default value). > 2. Close FF and reopen. Problem solved, I think, although I cannot test all > possible cases. These statements have proven not to be true. Under some circumstances the bug _can_ occur if the tabs are closed individually, and the workaround does not always work. As an experiment, I have had FF running for over a week. FF VM size has climbed to 142,704 K, with 619 handles. I have had up to 20 tabs open in one window and 6-8 tabs in a second window. It has been used mostly for Mozilla -- some for Google and a few miscellaneous sites. Everything was closed except for one tab in one window. Here is the refreshed about:cache report: Memory cache device Number of entries: 740 Maximum storage size: 18432 KiB Storage in use: 47640 KiB Inactive storage: 0 KiB > One user with a > serious problem, reported to me that the FF memory use was greatly reduced and > FF was much better behaved after he disabled the memory cache and reset the disk > cache capacity to 500000 kB. Disregard this statement. The user has retracted his statement privately. He still has the problem (which may not be related to this bug anyway). My system: FF1.0, only default extensions, plugins, and settings. WinXP SP1, 665 MHz, 384 MB, total paging file set to 576 to 1152 MB. Commit charge 310 MB, limit 944 MB. Conclusions: Bug can be duplicated as described, but it can be circumvented sometimes but not always.
Comment 7•20 years ago
|
||
What does this have to do with cache? The image nodes in the other tabs hold references to the cache entries. The image nodes don't go away until JS GC is run. JS GC is _not_ run immediately on tab closures, last I checked... Perhaps it should be?
Comment 8•20 years ago
|
||
(In reply to comment #7) > What does this have to do with cache? The image nodes in the other tabs hold > references to the cache entries. The image nodes don't go away until JS GC is > run. JS GC is _not_ run immediately on tab closures, last I checked... However, the images stay in cache even if I load a huge image after "Close other tabs". I've used the image https://bugzilla.mozilla.org/attachment.cgi?id=148944 from bug 178809. The image takes 30mb of memory cache.
Comment 9•20 years ago
|
||
Why is that a "however"? That matches with what I said, no?
Comment 10•20 years ago
|
||
I pointed out that cache entries are not evicted. It seems like a cache bug to me, no?
Reporter | ||
Comment 11•20 years ago
|
||
After reproducing this bug in Mozilla trunk build 2005013106, I've been repeatedly running a script that creates 1000 temporary arrays of 1000 objects. That should be making GC kick in, but the cache entries are still not being made inactive.
Comment 12•20 years ago
|
||
The cache entries cannot be evicted while the image nodes are holding a reference to the image data.
Comment 13•20 years ago
|
||
In the case where I close tabs one by one activating them first, Cache Memory drops to under 4mb and still holds some entries to cats images. Loading large image (larger than memory cache) will evict remaining cats images from the cache. Sorry if this brings nothing new to this bug. Just wanted to be more clear about my testings.
Reporter | ||
Comment 14•20 years ago
|
||
(In reply to comment #12) > The cache entries cannot be evicted while the image nodes are holding a > reference to the image data. Why would image nodes hold a reference to the image data long after I've closed the tabs the images were displayed in?
Comment 15•20 years ago
|
||
Because the image nodes have no idea that tabs exist, and because someone is holding a reference to them. The "someone" could be a script in a totally different window, btw, and it may decide to insert the image nodes into that document. Or it may decide to get the image data from the image node. The image nodes have no way of knowing any of this. All they know is that someone cares they exist.
Reporter | ||
Comment 16•20 years ago
|
||
(In reply to comment #15) > Because the image nodes have no idea that tabs exist, and because someone is > holding a reference to them. Then the question is why is the reference released when a tab is closed one way, but not when a tab is closed another way?
Comment 17•20 years ago
|
||
Yes, that is indeed the question....
Comment 18•20 years ago
|
||
Here's another experiment, using images on disk. I'm sorry if this adds to the confusion, but that's the way it is. Reproducible: Yes 1. Set browser.cache.memory.capacity to 4096 2. Open a new tab and go to about:cache 3. Open 6 new tabs and fill each of them with a .jpg image from the hard drive. I had a total of 11.7 MB compressed, and 66.3 MB uncompressed in FF Memory Cache. about:cache shows 66.3 MB after refreshing. 4. Check cache contents. The .jpg files are listed in the memory cache but not the disk cache. 5. Right-click on the about:cache tab and select Close Other Tabs 6. Reload about:cache tab noting memory usage Expected results: <4096 KiB Actual results: 158 KiB (the same as shown before loading the images). Conclusion(?): Astonishing as it seems, could comments 12 and 15 be correct? It's hard to imagine that any reference to those files remains. The memory should be allocated, and it is. $64 question: See comment 16. Someone (or better yet, several people), should reproduce this with the current build. ============= NOTE: NOT WITH CURRENT BUILD. I have FF 1.0, NO added extensions, plugins, or skins. Essentially default configuration except for step 1 above. Win XP, SP1.
Comment 19•20 years ago
|
||
Oops. Errata: Change that sentence in the conclusion to "The memory should be deallocated...."
Comment 20•20 years ago
|
||
See bug 250558 for a devastating example.
Comment 21•20 years ago
|
||
<b>The bug depends on the phase of the moon.</b> Sometimes I can reproduce it <i>consistently</i> (honest!), sometimes not at all. I came to realize the bug is erratic after failing to reproduce it with the nightly build of Mozilla, then noticing it disappear and later reappear in FF. I have followed SChapel's steps to reproduce exactly, but my results vary. See also invalid bug 250558, comments 17 and 19, for procedures to abandon up to 211 MB in cache! (I think that is this bug.) But note that with Benoit Dejean's procedure (bug 250558), he observed partial deallocation of memory, while I observe either correct behavior or no deallocation at all. With respect to this bug report, my comments that slightly different keystroke sequences trigger or block the behavior are, alas, suspect. All this is to say that your mileage may vary. If you don't observe it immediately, try later, or maybe try a slightly different keystroke sequence.
Comment 22•19 years ago
|
||
I think this bug was fixed by Bug 282938. I just tested 20050222 nightly build and the cache memory comes back to under 4mb after "Close other tabs". Reporter, can you verify that and close this bug.
Reporter | ||
Comment 23•19 years ago
|
||
I can still reproduce the problem with Mozilla trunk build 2005022305. I even tried repeatedly running JavaScript that makes and discards 1000 arrays of 1000 objects to make GC kick in, but the images are not being released from the cache. Maybe the fix for bug 131456 will help...
Reporter | ||
Comment 24•19 years ago
|
||
I can't reproduce with Mozilla trunk build 2005022405. A few seconds after closing the tabs, all the images that were on the tabs are flushed out of the memory cache. Can someone else confirm with one of today's trunk builds (Suite or Firefox)?
Comment 25•19 years ago
|
||
I shouted too early with 20050222 build. It does have problems. I was opening "cats" tabs differently, ie in the background. However, both 20050223 and 20050224 works fine for me. They release the cache memory.
Comment 26•19 years ago
|
||
Oh... and I'm using Firefox builds.
Reporter | ||
Comment 27•19 years ago
|
||
That all makes perfect sense -- Firefox builds were fixed on Feb. 21 by bug 283063, and the Suite got the fix on Feb. 23 by bug 131456.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•