Closed Bug 198806 Opened 22 years ago Closed 21 years ago

Image data memory leak resulting when images are saved (from browser tab)

Categories

(Core :: Networking: Cache, defect, P1)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.6beta

People

(Reporter: mmoy, Assigned: darin.moz)

References

Details

(Keywords: memory-leak, topembed+, Whiteboard: [ready-to-land])

Attachments

(1 file)

v1 patch
2.38 KB, patch
dougt
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030320 Phoenix/0.5
Build Identifier: (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030205)

I've had memory problems with Mozilla and Phoenix since last fall but today ordered more memory which should keep my up and running through the day. I noticed something peculiar in the about:cache results from Phoenix in that the Storage in use was many times higher than the Maximum storage size.

Memory cache device (Phoenix) (3/20/2003 label)

Number of entries: 1253
Maximum storage size: 4194304 Bytes
Storage in use: 58151463 Bytes
Memory cache usage report:

I tried to see if I could get the Storage in use: figure much higher in Mozilla (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030205) and found that I could after clicking on a bunch of links for a minute or two:

Memory cache device

Number of entries: 239
Maximum storage size: 4194304 Bytes
Storage in use: 9168804 Bytes
Memory cache usage report:

Is this a leak problem with cash entries not getting flushed out?

BTW, I checked the cache items on Phoenix and they added up to about 33 meg, much larger than the 4 meg cache.

FWIW: I typically use up about 300 MB on Mozilla or Phoenix with a regular day's
activity at which point I have to kill it or else XP will do it for me.

Reproducible: Always

Steps to Reproduce:
1. Do an about:cache
2. Visit a bunch of random pages doing about:cache from time to time until the
   Storage in use is more than the Maximum storage size by at least double.
3.

Actual Results:  
Storage was greater than the maximum size.

Expected Results:  
Flushed out items when the cache limit is reached.

I'm using LittleMozilla/LittlePhoenix, TabBrowser Extensions and Context
Menu Extensions.
->cache
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: asa → tever
I did some more playing around with this problem and found that I can get the cache usage up to 90 mb pretty quickly by loading several pages that have a lot of
images in them in separate tabs. When I close the tabs, the cache total goes down.

I normally run with several tabs that stay open for the whole day and they contain a few large images that get autoreloaded every few minutes. I used to use the meta tag but now I use TBE's autoreload feature.

One thing that I've noticed is that the memory usage grows as the cache usage grows but doesn't go down in size as the cache usage shrinks when closing tabs. Sometimes the cache usage will go up if I move from page to page using a particular tab.
Confirming with Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a) 
Gecko/20030402 and previous trunk build. I've just disabled memory cache to see 
whether it reduces enormous memory leaks that I encounter while browsing sites 
full of large images.
Mozilla 1.3.0 does not show such beahviour.
I tried installing the pref bar extension and using the Clear Mem Cache button
that it adds. The interesting thing is that it doesn't really change the amount
of memory Storage in Use but it does flush out all of the entries in the memory
cache usage report.
Right.  That's because any images you have in open tabs are currently using
memory.  By clearing the cache, you're saying "don't reuse these images", so if
the images are requested again additional memory will be allocated for them.

Open tabs is equivalent to open windows.  Each tab/window allocates memory for
the DOM tree, images, and whatnot.  Closing tabs/windows allows that memory to
be deallocated.  The cache allows images to be shared, potentially reducing
memory usage.

Michael, what build are you using?  I checked in some fixes for about:cache
accounting that are in 1.4a.

Radoslaw, could you describe the "leaks" you are experincing, and perhaps
include the about:cache stats (totals, not individual entries) when you seem to
have a large number of leaks?

Thanks.
The closing of tabs reducing the cache works shortly after I open the browser
in testing. In live use, the cache memory use goes up and up and up. It can
easily get to 100 MB by mid morning.

I did some more testing on this today and noticed that the memory cache was at
58 MB but the disk cache was only around 7 MB. Perhaps there are some expiration
problems too.

I generally use Phoenix and am mainly using the 3/20 nightly. I am using Release
1.3 for Mozilla. Could you tell me when your changes went in? I'll look at moving
to a later release sometime this weekend.
Okay great.  My changes went in 03/25 and are in 1.4a.  If it wasn't for comment
#3, I'd close this bug as FIXED now.  I'll wait to hear from Radoslaw before
closing it.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2
Target Milestone: --- → mozilla1.4beta
I installed Phoenix 4/1 which should have your fix in it. I managed to isolate the problem down a little more.

In general, I did a lot of playing around opening lots of tabs and many pages with a lot of images. Everything worked as expected. The cache usage went down as I closed tabs.

Then I hit reload on some pages with a lot of images and then closed the tabs. In this case, only a small portion of the cache memory was released. So the problem appears to be related to hitting the reload button. It's almost as if the memory in the cache is attached to the tab, then the reload refetches the page and creates a new cache entry and when the tab is closed the second copy in the cache is released but the first one isn't.

BTW, I checked the Moz version on Phoenix to verify that it was using 1.4a.
I've just re-enabled memory cache with latest Phoenix build
I have (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a)
Gecko/20030402 Phoenix/0.5). I went to http://www.kde.org/
and browsed screenshots, watching memory usage with WinNT
Performance Monitor. I opened 9 images in separate tabs,
memory usage went up for a moment, and then went down as
all images have finished loading.

There are two issues, though:

1. It seems that some memory has not been released
   (about 1 MB). I have yet to check it, but using
   previous trunk builds of Mozilla and Phoenix I
   was able to increase Private Bytes counter from
   the start-up value of ~15 MB to well over 50 MB.

2. About:cache shows something like that while loading
   and displaying images, and even *after* having closed
   all tabs containing images:

Number of entries: 	34
Maximum storage size: 	4194304 Bytes
Storage in use: 	20120288 Bytes

So, either it cannot count cache size or it cannot manage
memory properly.

Yesterday, using trunk Mozilla with memory cache disabled
I was unable to get it use as much memory as before (with
memory cache enabled), but it was not as much intensive
browsing, so I will try to test it more thoroughly.

After several hours of intensive browsing with memory cache
ENABLED (Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4a)
Gecko/20030402 Phoenix/0.5), displaying about:cache gives
such results:

Memory cache device:
Number of entries: 	195
Maximum storage size: 	4194304 Bytes
Storage in use: 	86188601 Bytes

Disk cache device:
Number of entries: 	353
Maximum storage size: 	4194304 Bytes
Storage in use: 	4189696 Bytes

All browsed tabs and windows closed, the only window
open is the one with 'about:cache' info. It certainly
can't count cache size (86 MB used out of 4 MB available?!?).
I'll keep this session open if possible to see whether it
also really leaks memory (Phoenix allocates about 12 MB
of Private Bytes memory at startup; at the moment it
consumes 28 MB, which is quite similar to Mozilla 1.3.0,
but stable version of Mozilla stabilizes memory usage
somewhere around 30 MB, while I think I've been able
to reach more with 1.4a trunk builds).

Regarding posts #9 and #10:

Are you watching VM usage as well as memory usage on Windows 2000? I run on XP
without a pagefile.
What I do monitor is:
- working set size
- private bytes (memory pages actually commited)
- virtual bytes (uncommited memory pages)

Virtual bytes counter shows 310 MB allocated at the moment
(still the same session of Phoenix). It has no impact on
system performance as these are uncommited memory pages,
but it also grows with time (I can't tell at the moment
what size of virtual area Phoenix allocates at startup
on my system, I can provide this information as soon as
I restart it).

Private bytes has grown to 38 MB now. It is what hurts
performance most, as it blocks quite an area of page
file.

Working set size changes with time as it should. I can
manually flush working set by minimizing application's
window, and while browsing it averages at 35 MB on my
256 MB RAM machine.

All this happens on Windows NT 4.0 SP6a, 256 MB RAM,
450 MB of page file.

Your usage numbers are similar to what I'm seeing. I usually had to kill Phoenix
at 300+ MB as it and my other applications would be near max memory on my system.
I bought another 512 MB recently so I have a GB and that gets me through the day
with Phoenix growing as large as it wants to.

Have you done any playing around with the reload button on pages with large
images? I have several pages with a lot of images that autoreloads through the
day. I was thinking of an experiment to popup a new window and close the old
one instead of meta-reloading to see if this makes a difference.
I tried the trunk and 1.4a, on Linux and WinXP, and the memory cache always
settles back down under Maximum storage size after closing all windows and tabs
(other than the about:cache window).  I also tried reloading and shift-reloading
pages with many large images.  Upon closing the page, cache memory return to
within limits.

Opening several tabs with large images is going to require a lot of memory. 
Decoded images are much larger than their file sizes would indicate.  We allow
active images to be added to the cache above the "maximum" limit to allow them
to be reused, thus reducing the overall amount of memory used.  When a tab or
window is closed, unused images above the cache capacity are evicted.

I'm concerned about Michael's comment #8 concerning reload, and Radoslaw's
comment #10 regarding memory cache stats with tabs and windows closed.  Michael,
could you post your about:cache stats after duplicating the "reload leak"? 
Radoslaw, could you verify the about:cache stats you posted were updated after
closing all tabs and windows (just reload the about:cache url)?

I appreciate your efforts in tracking down this anomaly.  Thanks.
Yes, I refreshed the about:cache window. In fact, I left Phoenix
for a night with only this one window open, and now even if
I refresh it I get:

Number of entries: 	148
Maximum storage size: 	4194304 Bytes
Storage in use: 	81245742 Bytes

And in cache entries list I have entries like that:

           Key: http://www.winsupersite.com/images/reviews/winnet_ho_000.gif
     Data size: 2359296 Bytes
   Fetch count: 1
 Last Modified: 04/04/03 10:20:23
       Expires: 04/21/03 04:17:10

www.winsupersite.com is the first site visited during this
Phoenix session. I opened it, displayed some screenshots
and closed the site -- and it stays in memory cache even
after several hours of browsing other sites.

I will try to check it with a newer build of Mozilla and
a brand-new profile.

I can't reproduce the problem with Mozilla/5.0 (Windows; U;
WinNT4.0; en-US; rv:1.4a) Gecko/20030404, even on my old
1.4.0a profile. Memory cache size shown in about:cache
exceeds maximum storage size, but it goes down after
closing tabs/windows. I'll download the latest Phoenix
build and see whether it's gone there too.
I'm very, very sorry, but I was too fast with my last
comment. It really seemed to work as expected, but after
more intensive browsing, it started to behave just like
before. I'll check with a clean profile again and this
time I'll wait with my conclusions ;)
I *think* I know how to reproduce problem:

1) open 10 images in separate tabs
2) wait till all images finish loading
3) refresh every one of them with F5 key
4) repeat steps 2) and 3) 5 times
5) check about:cache: images will be on list with fetch
   count of 5
6) close all tabs
7) check about:cache: images' fetch count will _decrease_,
   but they will not be released -- and they are likely to
   stay there forever

I achieved similar results by just saving images on disk.
Saved images would stay on about:cache item list with
fetch count of 1 even after having closed the tab.

All this with a fresh profile. I keep on investigating
the case :)

I played with this a little today on another machine with different nightlies
and found that I wasn't able to reproduce this with an older nightly, maybe 3/13
but had no problem reproducing this on 3/28. On 3/28, I could load two pages,
reload and then kill the tabs and then show cache usage above what it should
be.

One other comment for testing is that if you do the about:cache thing, and then
drill down to an individual cache record, it will increment the usage counter.
The cache report doesn't do this though.

I'm planning on trying one of the later Mozilla nightlies to test this problem
to see if I can provide a sequence to reproduce it that's fairly simple. I have
broadband at the office for this [I won't download Mozilla over dialup].
Radoslaw, are you using Context Menu Extensions?

I installed 2003-04-05 Mozilla fresh and could only reproduce this problem when
Context Menu Extensions was installed. Mozilla didn't reproduce it. Mozilla +
Tab Browser Extensions didn't reproduce it. But any combination with Context
Menu Extensions did reproduce this problem.

I have heard of performance complaints in the past with Context Menu Extensions
but not with Tab Browser Extensions.

Gordon, the extension is at http://white.sakura.ne.jp/~piro/xul/_ctxextensions.html.en if you want to try
it.

I'm a little perplexed as to how an extension could affect the cache like this.


I turned off the following Context Menu Extensions options:

General(1) -> Scroll Buttons -> Popup Area: turn them all off
General(1) -> Misc -> Custom Scripts: turn off
General(1) -> Misc -> Outline of Pages -> Update outline automatically when pages are loadad: turn off
General(1) -> Keyboard Shortcuts: turn off all options
Site Navigations -> Scan navigations automatically when pages are loaded: turn this off

And did a lot of testing and couldn't reproduce the cache memory problem. In
addition, I found that memory stability was much improved. My normal testing
would have brought me to 100 MB in the Task Manager in under a minute. I was
pretty steady around 32 MB with these options turned off. Note that this was in
Phoenix with the 2003-03-20 nightly so that this doesn't have anything to do
with the cache changes on 03-25. The real test will come on Monday when I do a
real day of browsing instead of these short-term tests.

One thing that was interesting was that only one of the options seemed to cause
the problem on Mozilla whereas there's either more than one or there is a
different problem on Phoenix.

From my perspective, if I don't run into any problems on Monday, then I'll
consider this closed.

Radoslaw hasn't indicated whether or not he's using context menu extensions
so it may still be an open problem for him.
I have no extensions installed. Just a fresh Mozilla nightly
with a fresh profile. I think that saving large images on
disk (open 20 images in separate tabs, wait for them to load,
and then save all of them with Ctrl+S, Enter, Ctrl+W)
is sufficient to reproduce the problem, but I have yet
to test it. However, I am pretty sure that the detailed
procedure I put in my previous comment does reproduce
the problem (I'll try to check it on another machine to
check whether it is OS dependent).
I didn't catch the Save Images part of your earlier post. Save Image is not
something that I do that much. I'll give it a try on Monday when I'm at the office
with broadband and have access to the latest versions of Mozilla and Phoenix.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326

Memory cache device

Number of entries: 	134
Maximum storage size: 	4194304 Bytes
Storage in use: 	11989411 Bytes

I am seeing this also.  I just found out about about:cache and noticed this today.
I can confirm the Save As problem. I was able to get the Cache in use over the
limit by a few megabytes with a number of image Save As commands. This was using
the Phoenix 3/20/2003 nightly.
Okay, excellent!  I can reproduce this.  I think something in the Save As...
mechanism is holding on to the image reference, keeping the item in the cache. 
It may be an ImgLib bug, or it might be a bug in one of it's clients.  I'll see
if I can track it down further.

Michael and Radoslaw, thanks for your persistence.
Please remember that it is not only Save As what
keeps redundant reference to the image in the memory
cache. My detailed bug reproduction procedure shows
that image reload causes the same leak too. They may
be two different bugs, or may be of same source.

Radoslaw, I have been unable to reproduce the problem with your steps without
saving the images.  After we've fixed the leak with saving images, we'll see if
that fixes the problems you're seeing as well.  If not, we'll keep investigating.
I was unable to reproduce the reload problem in my testing from last week. It
might be related, though, to something that Context Menu Extensions is doing
anyways that Radoslaw is seeing. Any chance of getting any more information
out of about:cache? Maybe an about:cache advanced which dumps the structures
holding locks on a cache entry.

The solution of disabling a few CME options has made a huge difference in
my browsing experience. I've sent a note to the maintainer on this. I suspect
that he is doing something in those options that is a bug with the browser but,
for now, I'm a happy camper. And I can at least tell others about the workaround
if they ask.

At some point, Piro may find out what he's doing that may be contributing to
the problem and then have me file a bug on it.
I think I'd like to change about:cache to break 'storage in use' into active and
inactive components.  Storage usage for inactive entries should always be less
than 'maximum storage size', while the memory cache allows active entries to
exceed it.

Radoslaw, as I was trying to reproduce the problem with your steps in comment
#18, I noticed something interesting.  You stated that after you closed the
tabs, the fetch count _decreased_.  We never decrement the fetch count for
objects in the memory cache, so the only way you could see them decrease is if
an entry was evicted and then stored back in the cache again as a new entry.

I've also noticed that if I have a single window, load a large image in it, then
type about:cache in the URL bar, it still reports memory used for the image.  If
I immediately 'reload' about:cache, the memory cache goes back down to below the
inactive maximum.  If I use a bookmark or history to go to about:cache, I may
have to hit the reload button a couple of times before the memory for the image
is finally released.  This *could* appear as if it was similar to the 'save
image as' memory leak, but I think there's just a bit of a delay between when
the about:cache protocol handler is called for the new page, and when the DOM is
released for the old one.

Radoslaw, could you try reproducing your results, but click the reload button on
about:cache a couple of times to see if the 'Storage in use' is consistent.  
I think I am no longer able to reproduce the "reload problem"
with the last trunk I have installed (2003041004). Perhaps
some bugs got fixed between 20030404 and 20030410? I'll keep
checking it, especially after the "save as" bug has been fixed.
I'm just testing 20030423 build of Phoenix. I can see
that the cache information has become more detailed
and that memory cache size is based on the machine's
physical memory size, but the "Save As" problem still
occurs:

Number of entries: 	210
Maximum storage size: 	13312 k
Storage in use: 	56859 k
Inactive Storage:	0 k

That's the new desired behaviour.  Though, if that's the case "Maximum storage
size" should become "Maximum inactive storage size" and should be on the line
above "Inactive Storage".

Now the question is why is mozilla using so much memory cache that is active?

Total up the bytes used by the 210 entries and see if it matches what's reported
in the summary.  Maybe there's an accounting problem as well as an object
aging/purging problem.
Radoslaw, re; comment #33, I wasn't expecting the recent landing to fix the
"Save Image As..." bug.  I'm still working on it.  Hopefully I'll have more time
to focus on it now that the other cache landing is out of the way.
I downloaded 4/29 of Firebird which has the new cache memory stuff in it. I was
wondering why the limit is so low. My system has a gigabyte of memory and the
Firebird limit is only 32 MB.
This seems like a bad regression.  Nominating for topembed and 1.4 blocker.

It isn't a problem with the memory cache, or possibly even imageLib.  Rather,
something is holding on to image references longer than necessary and eating
large amounts of memory.
Flags: blocking1.4?
Keywords: topembed
Summary: Cache memory leak? → Image data memory leak?
OS: Windows XP → All
Priority: P2 → P1
Hardware: PC → All
Discussed in edt bug triage.  Plussing.  nsbeta1.
Keywords: topembed → nsbeta1, topembed+
Flags: blocking1.4? → blocking1.4+
adt: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
setting keywords, severity, for memory leak...
Severity: normal → critical
Keywords: mlk
Blocks: 193865
Blocks: 203448
I can repeat this bug only for multiple tabs open, and then only if
I specify the memory cache size to be 4096K.
This was done on 1.4 branch version 2003060305, on win98 with 720M of ram.

See bug 204374 comment #66 for details.
Rob: in regards to bug 204374, are you saying that when you set a lower memory
cache size, you don't see (much) lost GDI resources, but you do see memory leaks
via this bug?  That might be a hint as to what is going on.  Could you go into
more detail?
I haven't explicitly looked for memory leaks, and as I have 720M of ram, I'm 
ulikely to see any swap thrashing to indicate memory problems.

A typical cache report will now show something like this:

Number of entries: 	261
Maximum storage size: 	4096 k
Storage in use: 	19115 k
Inactive Storage: 	0 k

If this is an honest report of the state of Mozilla's chache, then yes it 
implies a memory leak.


Randall, you asked: Could you go into more detail?
What kind of detail do you want?
In bug 204374 comment #66 I provided all the details I thought were relevant.
But forgot to add the following:
   OS: Win98sp2. Moz version: build 2003060305 from 1.4 branch.

I can do some  exploration of the memory consumption, if people
can tell me what tools to use to examine memory consuption, and what parameters
to monitor.

I've seen 'Storage In Use' larger than 'Maximum storage Size', but that's normal
when you have a page that uses more memory than you have in the memory cache.

Some porn pages can show that : for instance www.camwhores.com, and click on
'all webcams' (upper left). On my Mac, it went to 37502K, so I don't think it
works on Windows (bug 204374). When you close that tab or window, or when you go
back in the history, it should be recovered very quickly.

I remember a bug long ago, that explained that the currently visible images are
stored in 'expanded' form (JPG-compressed images seem to be stored as
non-compressed bitmaps f.i.), so that's why it's so large - you can't really
download 37MB on this page. I didn't see a memory leak on these pages, all
memory was released correctly. 
Re: comment #44

The situation you described is normal. However, saving images
on disk causes the memory cache memory not to be released.
I can reproduce _constant_ cache growth, even up to 60 MB
(with memory cache set to 4 MB with preferences). Memory
cache size stays at such high level even after having closed
all the windows and leaving the browser open for a whole
night.

What's worse, memory cache growth is associated with
virtual memory allocation and real page commits. Browser's
process _should_ stay at the level of ~30 MB of committed
memory, and I can bump it up to 70 MB just by intensive
browsing and saving large images on disk.

Memory cache growth has its impact on browser's performance
too. New window and new tab creation seem to take more time
when memory cache starts to be too large.

Clearing memory cache with preferences window brings numbers
shown by about:cache to sensible level, but it DOES NOT
release memory. "Virtual bytes" and "Private bytes" counters
(WinNT Performance Monitor) stay at too high level.

The bug started to appear in March builds and is present
even in latest 1.4-branch nightly. Mozilla 1.3.0 does not
show such behaviour.

I noticed that the memory will be released when you continue to surf. It might
take a while though before the dirty memory is 'pushed out' (bug 188458 changed
this a bit in Mozilla 1.4). Closing a tab will release some references too, and
seemed to speed up the release.

I noticed that saving an image does indeed prevent the image form being
released. Even closing the tab didn't help. But closing the window *did*
immediately help. Anyone that seems a continuously growing memory usage, please
close the tabs once in a while, and close the windows too. Both actions will
releases some references and free up memory.

Clearing the memory cache might help, but not if a resource is being kept by a
tab or a window. You're just removing the other images, not the one you're
trying to remove !

I think we have 2 bugs here :

- saving an image seems to hold onto some reference that prevents the release of
the memory. Only closing a window seems to help. This is a real bug.

- normal surfing seems to hold a few references too (especially since the
memory-cache is now much larger than it was in 1.3 !), but they seem to be
released during normal surfing (which can take a while) or when the tabs are
closed (a bit faster).
Bug 188458 has changed it a bit (it used to be first-fit, but that's
unpredictable), and bug 105344 (larger memory cache) are the cause the images
can stay much longer in the memory cache than needed. This has caused other
problems too (bug 2043740).
Maybe we also need to release data-blocks from memory that are older than -for
example- 5 minutes, but only if 'inactive storage' is 0 ? That will help us to
push out older blocks when we're running out of memory, without causing a big
performance slow-down ("throwing out the child with the water from its bath" as
we say here). The problem is that some pages really need enormous amounts of
memory, so you'll always see big spikes in memory usage.

Quick workaround for those that can't wait for a fix :
- close your tabs once in a while
- close your windows too, especially if you're saving images
- reduce your memory cache back to the old default : go to about:config and set
browser.cache.memory.capacity to 4096 (you might have to create the pref first).
 Especially if you're running on Windows (bug 204374). Just don't complain that
Mozilla becomes slower : a large memory cache really helps performance.
The symptoms of this bug have changed.  After saving an image, the extra memory
is released if no windows or tabs are displaying the saved image AND the window
that had been displaying the image is closed, or one of tabs in the window is
closed via the contextual menu (any tab, not just the tab that displayed the
image).  If the tab is closed via the close box, control-key, or menu item, the
memory is NOT freed.  Closing tabs in a different window also does not free the
memory.

Other bugs interacting with gdb are freezing the window manager, so I'm having a
difficult time getting stack traces.

...continuing to investigate...
This bug seems to go back in some form to between mozilla 1.1 and 1.2.  In 1.2,
saving the image isn't even necessary.  When I load a large image into a tab,
the cache reference is held after the tab or even the window is closed.

So we've actually improved since 1.2, since now it's a bit harder to trigger and
there are certain (obscure) ways in which to recover the leaked memory.

...continuing to investigate...
Depends on: 209354
Flags: blocking1.4+ → blocking1.4-
QA Contact: tever → cacheqa
I noticed that saving images causes the Windows NT file
cache working set to grow, what suggests that file handles
are not being closed. It looks similar to bugs 148427, 171681
and 179498 (fixed after 1.2.0 release, which had enormous
problems with image memory management).

Closing mozilla.exe process causes the cache working set
to shrink. I can't make it shrink by closing individual
Mozilla's windows or tabs.
See bug 199443; in particular the patch there.
*** Bug 210718 has been marked as a duplicate of this bug. ***
*** Bug 210773 has been marked as a duplicate of this bug. ***
*** Bug 210003 has been marked as a duplicate of this bug. ***
This bug is likely fixed with the patch for bug 209354.  As soon as I verify
that, I'll close this bug.
Well, it's better, but not ALL better. The imgRequest is still being held longer
than necessary through nsFocusController->mPopupNode (via an nsHTMLImageElement
and a chain of other objects - nothing is ever easy).

Continuing to debug.
Changing target milestone as 1.4beta has been and gone. Hoping for 1.4final (as
I'm sure many others are), but also not assuming too much as things change as
resources priorities move around. Mind you, this isn't blocking 1.4final, so it
may well change.
Target Milestone: mozilla1.4beta → mozilla1.4final
OK, I see this too (nsFocusController->mPopupNode is being held) until 
either shutdown OR you do another popup on another window (hence 
mPopupNode is reset via nsFocusController::SetPopupNode).

correction, the addref'ing is done in nsFocusController::GetPopupNode
You're right in both cases Jim.  mPopupNode is an nsCOMPtr, so it gets addref'd
upon storage in SetPopupNode() and whatever *was* stored in mPopupNode gets
released.  That's why it's on the stack when the imgRequest is finally released.
Blocks: 211643
As requested from: http://bugzilla.mozilla.org/show_bug.cgi?id=211643

How to make your Mozilla/Firebird have display issues:

http://robh.net/test.html

Have this page open, open the link in a new tab. Wait for it to load, then try
to switch back to this tab. This affects Firebird nightlies as well as Mozilla
1.4. I'm using Windows XP Pro, SP1.
Re: comment #54

The Save Image Issue is still here. The latest Firebird build
("Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a)
Gecko/20030714 Mozilla Firebird/0.6") still bloats memory
cache when saving images on disk. First image save causes
another interesting symptom: opening new tabs and windows
with uncached contents takes much more time than before
saving an image, while opening new tabs and windows with
cached contents is instantaneous.

As I stated in comment #49, file handles are probably not
being released, what causes the Mozilla's and file cache's
working sets to grow.

Mozilla also does not release the memory of images if image resizing is turned
off (browser.enable_automatic_image_resizing set to false).
*** Bug 205662 has been marked as a duplicate of this bug. ***
detailed steps to reproduce this bug can be found here:

http://bugzilla.mozilla.org/show_bug.cgi?id=205662#c9

-> me
Assignee: gordon → darin
Status: ASSIGNED → NEW
Target Milestone: mozilla1.4final → mozilla1.6alpha
Status: NEW → ASSIGNED
Summary: Image data memory leak? → Image data memory leak resulting when images are saved (from browser tab)
i can easily reproduce this bug using the steps i linked to in the previous
comment.  firebird is currently consuming 102 MB, and the memory cache reports:

 Maximum storage size: 	 31744 k
 Storage in use: 	106170 k

investigating...
Attached patch v1 patch — — Splinter Review 
nsURIChecker was being bad.  it creates reference cycles and doesn't bother to
break them.
Attachment #134429 - Flags: superreview?(bz-vacation)
Attachment #134429 - Flags: review?(dougt)
Comment on attachment 134429 [details] [diff] [review]
v1 patch

Oops.  Mea culpa.  sr=bzbarsky.
Attachment #134429 - Flags: superreview?(bz-vacation) → superreview+
Comment on attachment 134429 [details] [diff] [review]
v1 patch

i am a bit worried about the cycle.  makre sure we don't leak with the refcnt
balancer. r=dougt
Attachment #134429 - Flags: review?(dougt) → review+
yup, refcnt balancer is definitely happy.  it's what told me to look at
nsURIChecker in the first place! ;-)
1.6a appears to have been tagged... probably not worth it to squeeze this fix in
for alpha.  it can wait until beta.
Target Milestone: mozilla1.6alpha → mozilla1.6beta
Whiteboard: [adt2] → [ready-to-land]
fixed-on-trunk (for 1.6 beta)
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 134429 [details] [diff] [review]
v1 patch

+    // break cycle if we fail to open the channel.
+    if (NS_FAILED(rv))
+	 mChannel = nsnull;

should you also set mObserver to nsnull here, like in OnStopRequest (which
won't be called if AsyncOpen failed)?
good catch biesi... actually, there's a lot i'd like to revise in nsURIChecker.
 i filed bug 224240 to fix that and do some other housekeeping on nsURIChecker.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: