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)

Product:
Core
Component:
Networking: Cache
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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.
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.
(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
(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.
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. 

(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.
(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.
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?
(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.
Why is that a "however"?  That matches with what I said, no?
I pointed out that cache entries are not evicted. It seems like a cache bug to
me, no?
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.
The cache entries cannot be evicted while the image nodes are holding a
reference to the image data.
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.
(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?
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.
(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?
Yes, that is indeed the question....
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.
Oops.  Errata:  Change that sentence in the conclusion to "The memory should be
deallocated...."
See bug 250558 for a devastating example.
<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.
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.
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...
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)?
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.
Oh... and I'm using Firefox builds.
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.