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.
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.
Summary: Cache memory leak? → Image data memory leak?
setting keywords, severity, for memory leak...
Severity: normal → critical
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...
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.
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...
nsURIChecker was being bad. it creates reference cycles and doesn't bother to break them.
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
fixed-on-trunk (for 1.6 beta)
Status: ASSIGNED → RESOLVED
Closed: 16 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.