Closed Bug 320915 (mlk1.8) Opened 19 years ago Closed 16 years ago

[Meta] 1.8 memory leak campaign

Categories

(Core Graveyard :: Tracking, defect)

Product:
Core Graveyard
Component:
Tracking
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: dveditz, Assigned: dveditz)

References

Details

(Keywords: memory-leak, meta, regression)

Attachments

(1 file)

Snapshot of Firefox using over 400 MB of actual memory.
127.62 KB, image/jpeg
Details 
Compared to the 1.7 branch (Firefox 1.0) lots of people are complaining that the 1.8 release (Firefox 1.5) leaks tons more memory. We're getting lots of dupes (an invalid) bugs to that effect, some negative press articles, and some of us are seeing it ourselves.

This meta bug tracks the effort to find and fix these leaks, and to figure out which should be applied to the 1.8 branch, and which are important (and safe) enough to go into a 1.8.0.x release.
Alias: 1.8mlk
Alias: 1.8mlk → mlk1.8
Depends on: 241518, 309381, 319262
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Depends on: 319980
Depends on: 316775
Can bug 296538 help a little to avoid the biggest critics ?
You might want to read some of the comments in https://bugzilla.mozilla.org/show_bug.cgi?id=213535 since they give some easy ways to get Firefox to use an extreme amount of memory.

Also some extensions can cause Roboform to use more memory than normal.  Roboform is one of them (though they claim to have fixed the major memory leak in their extension).

There is also https://bugzilla.mozilla.org/show_bug.cgi?id=130157 (large pages cause memory leaks) and https://bugzilla.mozilla.org/show_bug.cgi?id=289198 (flash causes memory leaks).
Of note one of the Roboform programmers informed me that "Firefox 1.5RC2 itself has memory leak on each click on link (its internal leak detector reports 15 leaked objects per each link click)."  

I don't know if this was fixed for the 1.5 release or not.
dbaron is working on a "better way for users/testers to detect and isolate leaks of large object graphs" (bug 320192).
Summary: 1.8 memory leak offensive → 1.8 memory leak campaign
No longer depends on: 319980
Depends on: 305208
Depends on: 302737
Depends on: 317708
Depends on: 319123
I've also noticed this, and it's been very annoying. Done a small amount of testing, to find there appear to be two issues here.

First, resource hogging by bfcache, and second memory leaks.

The second problem is an issue of tracking down bugs. The first problem is a design issue that is making the second problem worse.

Bfcache appears, from what little testing I've done browsing with it switched on and off, there is a fundamental issue with bfcache that is making the memory leaks appear worse. With it switched on, memory leaking happens faster, and flash sites use up a lot of CPU, even when you have browsed away from the page with the embeded object. I think these problems may be inherent in the whole concept of keeping previously browsed pages in rendering.

As a bandaid fix, can I suggest releasing a config patch to set browser.sessionhistory.max_total_viewers = 0 

While this won't fix the underlying memory leak issues, it will improve performance considerably.
No longer depends on: 317708
So is this bug about memory leaks in general, or about memory leaks that are regressions from 1.7?
(In reply to comment #7)
> So is this bug about memory leaks in general, or about memory leaks that are
> regressions from 1.7?

This bug is about leaks important enough to get fixed on the 1.8 branch. I expect these primarily to be post-1.7 leaks since the bulk of the complaints have been "how much worse" 1.5 is. But we wouldn't turn down a big non-regression leak if it's not overly risky or API-busting.

I wouldn't necessarily limit the scope to true leaks, either. If we've got a particularly bloaty new feature we can slim down that'd be good, too.
I'm not sure what's causing this, but I can document that after some heavy surfing with Firefox 1.5 opened for around 6 or 7 hours, it is now using over 400 MB of memory.  Here's an image to show the memory usage and cache usaged.  Notice the memory cache usage is greater than the max, but this still doesn't explain where the remaining 320 MB of memory went.

I estimate that if I were to continuously surf for around 35 hours that Firefox would use all 2 GB of my RAM.

In my case I think the Roboform extension is still partially to blame (despite the authors telling me there are no leaks in it), but there are still issues in Firefox itself.
I'd like to nominate these for inclusion in the campaign:
* Bug 321282, Loading Gmail leaks six DOMWindows.
* Bug 321283, using Find causes documents to leak.

Does it make sense to put the code from bug 320192, "better way for users/testers to detect and isolate leaks of large object graphs", on the 1.8.0.x branch?  I think it doesn't affect normal release builds, but having it there would make it easier for testers to determine what big leaks remain on the branch.
Consider Bug 321661. It has steps to reproduce the bug and behaviour is different from firefox 1.0
Note that the latest version of Adblock (both 0.5.2.056 and 0.5 d3 nightly 40 ; these should work in 1.5) never seem to release items from the memory cache. Inactive storage stays at 0, Storage in use keeps growing without bounds. This even happens when Adblock is disabled. Adblock Plus 0.5.11.1 seems to work fine.

I know that we shouldn't complain about extensions here, but since so many people are using Adblock, we'll receive many reports about it.
DBaron - on Comment 10 - is this feasible/advisable for the branch?  
Opener of Bug 321760 has reported following workarounds of "eating-up memory problem" in his environment to Bug 321760 Comment #7.
> (1) set browser.sessionhistory.max_total_viewers = 0 
> (2) installed AdBlock Plus instead of AdBlock
(1) is workaround of Bug 321661(probably DUP of Bug 306862), and (2) is workaround of suspectable memory leak by AdBlock.
(In reply to comment #12)
> Note that the latest version of Adblock (both 0.5.2.056 and 0.5 d3 nightly 40 ;
> these should work in 1.5) never seem to release items from the memory cache.

AdBlock currently available at addons.mozilla.org is Adblock 0.5.2.056 which was released on November 29, 2005.
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1
And a comment on December 19 2005 says(as of today, this is put in page 5) ;
> Do NOT install Adblock 0.5.2.056
> by andy, Monday, December 19 2005
>
> Go to the site below for the latest Adblock 0.5.3.040.
> http://adblock.ethereal.net/Adblock_v.5/adblock-05-dev.xpi
> Adblock 0.5.2.056 has a memory leak problem.

Jo Hermans, is your "0.5 d3 nightly 40" the Adblock 0.5.3.040?
(In reply to comment #15)
> (In reply to comment #12)
> > Note that the latest version of Adblock (both 0.5.2.056 and 0.5 d3 nightly 40 ;
> > these should work in 1.5) never seem to release items from the memory cache.
> 
> AdBlock currently available at addons.mozilla.org is Adblock 0.5.2.056 which
> was released on November 29, 2005.
> https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1
> And a comment on December 19 2005 says(as of today, this is put in page 5) ;
> > Do NOT install Adblock 0.5.2.056
> > by andy, Monday, December 19 2005
> >
> > Go to the site below for the latest Adblock 0.5.3.040.
> > http://adblock.ethereal.net/Adblock_v.5/adblock-05-dev.xpi
> > Adblock 0.5.2.056 has a memory leak problem.
> 
> Jo Hermans, is your "0.5 d3 nightly 40" the Adblock 0.5.3.040?
> 

yes, it seems so.

The problem is that the advertised version is Adblock 0.5.2.056, which is also the one that is automatically downloaded. When you try to upgrade to a new version with the update-mechanism, this is the latest version available. And that's the one with the biggest, easiest reproduceable bug (just use, memory will never be released).
Dan - thanks for filing this bug. I just wanted to note that there have also been reports of Thunderbird leaking memory, and I have experienced it myself on the Mac. Do you want me to create a separate bug for Thunderbird?
Depends on: 322056
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.2+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
You'll notice that memory leaks have continued to grow as shown by the searches in this mozillazine posting:

http://forums.mozillazine.org/viewtopic.php?t=141658&postdays=0&postorder=asc&postsperpage=15&highlight=mlk+memory&start=30
Depends on: 323074
(In reply to comment #16)
> The problem is that the advertised version is Adblock 0.5.2.056, which is also
> the one that is automatically downloaded.

Adblock 0.5.3.040 was released on January 11, 2006 at addons.mozilla.org.
See https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1

Jo Hermans, are you still experiencing severe memory leak by Adblock even after official Adblock 0.5.3.040?
(In reply to comment #20)
> (In reply to comment #16)
> > The problem is that the advertised version is Adblock 0.5.2.056, which is also
> > the one that is automatically downloaded.
> 
> Adblock 0.5.3.040 was released on January 11, 2006 at addons.mozilla.org.
> See
> https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1
> 
> Jo Hermans, are you still experiencing severe memory leak by Adblock even after
> official Adblock 0.5.3.040?
> 

Yes, using Adblock v.5 d3 * nightly 41 (although it's labelled as 40 in the preferences window). 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060113 Firefox/1.5.0.1
I'm running on Mac OS X 10.2.8

It seems that Adblock prevents *every* image in the memory-cache from being uloaded - even when it's disabled, or when no image-blocking rule was active (the default immediately installing Adblock). I watched using about:cache?device=memory , but I never saw an image being unloaded (html-files, yes). After a few websites, my 9MB memory cache was full, but never shrank. "Inactive storage" was 0, or a few KB's at most (when a html-file was evicted). After the 9MB was reached, it stayed at 0.

Only other extension that I'm running is Chatzilla, latest version.
*** Bug 309381 has been marked as a duplicate of this bug. ***
(In reply to comment #21)
> Yes, using Adblock v.5 d3 * nightly 41 (although it's labelled as 40 in the

> It seems that Adblock prevents *every* image in the memory-cache from being
> uloaded - even when it's disabled, or when no image-blocking rule was active
> (the default immediately installing Adblock). 

Adblock 0.5.3.042 has been released on January 15, 2006.
https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1

Jo Hermans, do you still have memory leak problem by AdBlock, even when newest version of AdBlock?
Does your memory leak problem(AdBlock is suspectable) occur even when only AdBlock is installed?
No possibility of memoly leak by other than AdBlock?
(Sorry but I'm not a user of AdBlock. I install Tab Browser Extentions and LiveHTTPHeaders only.)
(In reply to comment #23)
> Adblock 0.5.3.042 has been released on January 15, 2006.
> https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1
> 
> Jo Hermans, do you still have memory leak problem by AdBlock, even when newest
> version of AdBlock?
> Does your memory leak problem(AdBlock is suspectable) occur even when only
> AdBlock is installed?
> No possibility of memoly leak by other than AdBlock?
> (Sorry but I'm not a user of AdBlock. I install Tab Browser Extentions and
> LiveHTTPHeaders only.)

It seems indeed that it was solved by Adblock v.5 d3 * nightly 42. If this new version gets distributed with automatic updates, it might fix most complaints, since I often see people mentioning Adblock when asked for their extensions. Let's just hope that people with manual updates will be so clever to try to update their extensions, before firing another angry bug-report.

For the record, I could demonstrate the leak by installing Adblock without any installed rule, and even when this it was diabled. The memeoyr leak was fixed when I uninstalled it. Only Chatzilla was installed, no other extensions.

Daniel Veditz, I think Bug 314549 is better to be put in dependency tree of this bug.
(Memory leak issue is involved when document has subframes. Bug 314549 is found during processing of Bug 314288.)
(In reply to comment #23)
> Adblock 0.5.3.042 has been released on January 15, 2006.
> https://addons.mozilla.org/extensions/moreinfo.php?application=firefox&numpg=25&id=10&page=comments&pageid=1
> 
> Jo Hermans, do you still have memory leak problem by AdBlock, even when newest
> version of AdBlock?
> Does your memory leak problem(AdBlock is suspectable) occur even when only
> AdBlock is installed?
> No possibility of memoly leak by other than AdBlock?
> (Sorry but I'm not a user of AdBlock. I install Tab Browser Extentions and
> LiveHTTPHeaders only.)
> 

I have now been running 2 days continously on Windows without any major problem (comment 24 was on Mac OS X 10.2.8), I didn't even restart FF. The VM size is 82 MB, memory cache is always below the limit of 16MB (can be higher when the page requires, but it always falls back after that). Very stable. I have been surfing on normal websites, image-happy ones, ssl-sites, flash-sites, ... The only thing I didn't do was Java, because it's disabled. Only other extesnion is the Tab Sidebar 1.0.1.

Adblock v.5 d3 * nightly 42
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

(In reply to comment #26)
> memory cache is always below the limit of 16MB
> (can be higher when the page requires, ...)
For your information:
"can be higher than limit of 16MB" is phenomenon of Bug 213391.
New NSPR logging code for memory leak detection is now available(trunk builds from 2005-01-06 or newer), and tool for log analysis is also available.
See http://dbaron.org/log/2006-01#d20060114 for the tool(leak-gauge).
D. Baron kindly implemented HTML/JavaScript version in addition to Perl script version, especially for MS Win users who don't have Active Perl(majority of MS Win users).
See comment #5 and bug refered in it for detail.

Comparing tool's report of next cases will help problem analysis when memory leak is suspectable.
 (1) With current profile, with extentions you are using.
 (2) With new profile, with no extention.
 (3) With new profile, with a(only one) suspectable extention(or theme).

To opener of bug of "Memory leak in my PC!" and commenter of "Me too!" :
 Please test at least above three test cases.
 (If possible, both with your using build and with newest trunk build.)   
 And please read http://dbaron.org/log/2006-01#d20060110 and
 http://dbaron.org/log/2006-01#d20060122 before open bug saying "memory leak".
Depends on: 213534
Depends on: 249469
Depends on: 326611
No longer depends on: 213534
Depends on: 269523
(In reply to comment #28)
>  And please read http://dbaron.org/log/2006-01#d20060110 and
>  http://dbaron.org/log/2006-01#d20060122 before open bug saying "memory leak".
> 
could someone come up with a firefox extension with a helpful friendly GUI for these? without a helpful GUI, not many people who know how to file bug but not how to get this to work will be unable to help with memory leaks... thanks.

I also posted this suggestion to bug 319262
thanks again.


meta bugs don't block
Flags: blocking1.8.0.2+
Summary: 1.8 memory leak campaign → [Meta] 1.8 memory leak campaign
In addition to my Firefox 1.51 and Deer Park Alpha 2 taking up between 90-130mb of memory, they sometimes hog 99% of my CPU even when nothing is going on.
I've found a very good example of very heavy memory usage on a single page :
steps to reproduce : 
- start the last firefox version 1.8.0.1 (actually 1.5.0.1 I still don't understand the way of numbering) gecko/20060111
- open http://facs.scripps.edu/surf/images/euranim.gif (the real picture size is only 2Mo)
- look at the memory  usage for firefox grow up to 700Mo using between 50 and 100% of processor ! with only a single picture loaded just after the start, without any use of tabs ! 

then after nearly five minutes of system hanging, the firefox memory usage suddenly drop to 50 Mo...
Then if you click refresh, the cycle restart...
(In reply to comment #32)
> then after nearly five minutes of system hanging, the firefox memory usage
> suddenly drop to 50 Mo...
> Then if you click refresh, the cycle restart...
> 

Sharp jump here too:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060406 Firefox/2.0a1 - Build ID: 2006040603

Looks like the animation is causing a few problems.
(In reply to comment #32)
> - open http://facs.scripps.edu/surf/images/euranim.gif

Sounds like bug 94828 and bug 105370. The high memory usage is not due to a memory leak, so does not have anything to do with this bug report.
(In reply to comment #34)
> (In reply to comment #32)
> > - open http://facs.scripps.edu/surf/images/euranim.gif
> 
> Sounds like bug 94828 and bug 105370. The high memory usage is not due to a
> memory leak, so does not have anything to do with this bug report.
> 
don't you think that when the load of a single picture consumes 700 Mo of ram there's a memory leak ?

(In reply to comment #35)
> don't you think that when the load of a single picture consumes 700 Mo of ram
> there's a memory leak ?

Not if the memory is ever released, absolutely not! A memory leak is when memory is allocated and never deallocated, not excessive memory usage. Note I didn't say the problem isn't a bug -- just not a leak. That is, unless someone can show that the memory isn't ever released. Let's continue general memory leak discussions on MozillaZine so we don't generate more bugspam, okay?
I would like to nominate these bugs:
bug 334255 - contains leak gauge data that shows leaks with flash
bug 334322 - flash ads (*.swf) cause memory growth, reduced testcase shows 100MB per hour! 
The latter bug (filed by me) is NOT a memory leak, but is causing much of the slowly growing memory bloat people complain at, since many sites nowadays use flash ads. Therefore is is important that it will be fixed in the 1.8 memory campaign, even if it is not a memory leak, and even if it is found that it is caused by the flash plugin, not Firefox.

The memory is released, yes but after five to ten minutes of system hanging ! Do you realize, that many people would have rebooted a long time before the memory would be released. Furthermore, perhaps it would be useful to know what on earth is doing firefox with this huge memory just to load a single animated gif... and It could help fixing other memory problems... I'm not in the code, I only try to detect and signal obvious problems... 
Not going to block 1.8.1 for a tracking bug.
Flags: blocking1.8.1+ → blocking1.8.1-
No longer depends on: 323074
No longer depends on: 321760
No longer depends on: 312597
No longer depends on: 309381
No longer depends on: 319262
Please see bug 342810 - Memory usage grows by ~10MB per minute (probably memory leak)
It is on the trunk, not on the 1.8 branch, but since there is no "memory leak campaign" meta bug for the 1.9 branch or trunk, and the bug is critical, and no one responded for a few days, I bring it up here since I need someone to confirm it and take it to resolution.

*** Bug 268138 has been marked as a duplicate of this bug. ***
(In reply to comment #31)
> taking up between 90-130mb of memory,
(In reply to comment #32)
> the memory usage for firefox grow up to 700Mo
> the firefox memory usage suddenly drop to 50 Mo...
(In reply to comment #38)
> The memory is released, yes but after five to ten minutes of system hanging
(In reply to comment #40)
> Memory usage grows by ~10MB per minute

What do you mean by your "memory" or "memory size"?
Number displayed at "Memory Usage" column of process of Image-name=firefox.exe in Process Tab of Task Manager? Or "Virtual Memory Size" column in Process Tab?
Or "Memory Usage" in Performance Tab of Task Manager? (When Win-2K. When Win-XP, different title is used for system wide virtual memory size(=real memory size of PC + swap file size).

Distinguish phenomenon relates to "Real memory(size increase)" with phenomenon relates to "Virtual memory(size increase)" clearly.
If you are talking about phenomenon on MS Windows and talking about number displayed in "Memory Usage" column for Firefox, check next first.
 (0) View at least both "Memory Usage" column and "Virtual Memory Size" column
     of Task Manager.
     (or get "Counter log" for "Process". When Win-2K, thru "Perfomance" or )
     ("Management of Computer"(may be Computer Management) in Control Panel.)
 (1) Change config.trim_on_minimize from false(this is default) to true
     thru about:config, then restart Firefox.
     Please don't forget to use new profile(at least start with -safe-mode),
     because we are not testing for extension's memory leak problem.
 (2) Use Firefox
 (3) When you feel number of "Memory Usage" column is very large,
     (3-0) Check number displayed as "Memory Usage"/"Virtual Memory Size".
     (3-1) Minimize all Firefox windows
     (3-2) Check number displayed as "Memory Usage"/"Virtual Memory Size",
           and wait for a while (several to 10 seconds is sufficient) 
           => When config.trim_on_minimize=true, MS Win's memory management
              gets "already freemain'ed real memory" back to page pool,
              and start to remove real memory allocated to virtual memory
              used by Firefox(allmost all alloctaed real memory if minimized
              long time), and start to keep real memory for system cache.
              See activity by MS Win at "Performance Tab" also. 
     (3-3) Change all Firefox windows back to normal size
     (3-4) Switch tab several times until no severe tab switch delay is observed
     (3-5) Check number displayed as "Memory Usage"/"Virtual Memory Size"
     (3-6) Continue to use Firefox for a few minutes
           => Number displayed at "Memory Usage" column at this step is
              near size to really required "Working Set" size at this stage.
Is there any difference among number at step 3-0, 3-2, 3-5 and step 3-6?
Is there any difference from result when same test with config.trim_on_minimize = false ?
(same actions/web sites at step 2 & step 3-6, and near threshold of "Memory )
( Usage" & "Virtual Memory Size" at step 3)

(In reply to comment #42)
[...]
>  (1) Change config.trim_on_minimize from false(this is default) to true
>      thru about:config, then restart Firefox.
[...]
config.trim_on_minimize does not normally appear in about:config (at least not in Fx 1.5.0.7 nightly, which is what I use). It is of course possible to create it, using "rightClick -> New -> Boolean"; but will Firefox use it? I seem to vaguely remember the most apparently knowledgeable people saying that that was a Mozilla-Suite-only preference, unused by Firefox.
(In reply to comment #43)
> config.trim_on_minimize does not normally appear in about:config

This is true on all SeaMonkey trunk, Firefox trunk and Thunderbird trunk.
And when config.trim_on_minimize=true is reset manually, attribute was changed from Boolean to String(no text is set).
To return to initial status(no display in about:config), reload of about:config was required(test result with SeaMonkey trunk).

> It is of course possible to create it, using "rightClick -> New -> Boolean"; but will Firefox use it?

Behavior when config.trim_on_minimize=true is same on at least following three trunk builds(Win-2K), i.e. number displayed in "Memory Usage" column of Process Tab of Task Manager is reduced to very small when minimized.
 - SeaMonkey trunk(Win-2K)
 - Firefox trunk(2006/09/05 build/Win-2K)
 - Thunderbird trunk(2006/07/05 build/Win-2K)
 ("Memory Usage" column seems to correspond to counter="Working Set" of)
 ( performance object="Process" of Counter Log                         )

Do you mean config.trim_on_minimize=true didn't work in your environment?  
(In reply to comment #44)
> (In reply to comment #43)
[...]
> Do you mean config.trim_on_minimize=true didn't work in your environment?  
> 

What I'm using today is "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060913 Firefox/1.5.0.7" - Build ID: 2006091304 - on SuSE Linux 9.3.

It's hard for me to tell whether or not config.trim_on_minimize makes any difference. When I'm browsing, Firefox's memory use normally varies only slowly; and when I'm temporarily doing something else, minimizing it is not my usual practice. I just minimized it for several minutes (obviously I had to un-minimize it again to type this comment) and saw no discernible change in memory use, which (according to ksysguard) is currently in the 400 MB range for Firefox, together with X, and far "ahead" of everything else including Thunderbird (which is in the 100 MB range). I'm talking "VmSize" here; "VmRss" (whatever it is) is around 322 MB firefox-bin, 144 MB X, 62 MB thunderbird-bin, all other processes are lower. This is at something like 20 hours' uptime, but I've been sleeping part of that time.

About comment #0 : personally I'm seeing about the same kind of subjective bloat in Firefox 1.5.0 as I used to see in 1.0.x, or even slightly less (or maybe it's because I've expanded my total RAM size, currently 1GB). Of course, all other things being equal, the smaller the better.
(In reply to comment #45)
> (X11; U; Linux i686; en-US; rv:1.8.0.7)
Oh, Linux.
As far as I understand, config.trim_on_minimize=false/true has meaning only when MS Windows(NT or later). So I said "If you are talking about phenomenon on MS Windows" in comment #42.
  1) Original behavior was same as one with config.trim_on_minimize=true
  2) Bug 76831 opened, and many complaints, then config.trim_on_minimize was
     created by Bug 76831 Comment #275. (#275! default was true at this point)
  3) Much more complaints, then config.trim_on_minimize=false was defaulted
     by Bug 76831 Comment #353. (77 comments after #275...) 
  Enjoy flood of complaints in Bug 76831 :-)
I think that delay in "releasing of allocated real memory to already freemain'ed virtual memory" is not so big problem when Linux, because I believe memory management of Linux is better than MS Win.
Sooner or later, "real memory for freemain'ed virtual memory" is freed even when no minimize of window, isn't it?
Does "virtual memory size" used by Firefox increase infinitely?
Does working set size increase infinitely too?

> I've expanded my total RAM size, currently 1GB
See about:cache / Memory cache device / Maximum storage size:
If very large, reduce it manualy. (set browser.cache.memory.capacity. unit: KB)
(Addition to comment #42)
>      (3-1) Minimize all Firefox windows
Minimize EACH Firefox window when minimize all Firefox windows.
Don't use "minimize all" command. (See Bug 323594)
No longer depends on: 342810
I have an idea to research memory leaks. Could an extension be developed for reporting memory leaks to the development team. Mostly, it would report how many tabs were opened and closed, how long Firefox was running. I know this is pretty much spyware, but if it is an extension it would be voluntary.
(In reply to comment #49)
> See https://addons.mozilla.org/firefox/2490/
> 

could anyone extend that addon? make it somehow easier to use? integrate it with filing bugs for example?

also, it seems it only points to javascript that leaks (though I'm not sure what I'm talking about):
"It warns when chrome windows close but leave other code pointing at their JavaScript objects."
I see that there are only 2 bugs that depend on this (part of the campaign), however there are bugs out there that should be added here. Example is bug # 341872, which even has a patch attached. are there plans to search for and include more memory leak bugs to this campaign? I hope so -thanks. 
about:cache?device=memory reports on K/Ubuntu 6.10 with 512-64 MB RAM:

Memory cache device

Number of entries: 	1041
Maximum storage size: 	13312 KiB
Storage in use: 	75086 KiB
Inactive storage: 	0 KiB

How can used storage exceed max storage?


All open memory leak bugs: 
ttps://bugzilla.mozilla.org/buglist.cgi?keywords=mlk&resolution=---
(In reply to comment #52)
> How can used storage exceed max storage?

See bug 213391. The current 'maximum storage size' is not a hard limit, a page might need more in order to display its contents. And there's also the back/forward cache.


Thunderbird version has appeared recently - Bug 378077.
Depends on: 378077
This is slightly OT, but I don't think it makes sense for the browser to be caching in memory at all.  If there is available memory, the OS should cache stuff from the disk cache in memory, making the browser's memory cache redundant.  I've been running Firefox with browser.cache.memory.enable=false and browser.cache.memory.capacity=0, and I haven't noticed any degradation of my browsing experience.

However, it hasn't alleviated the memory usage problem at all.  Right now, gnome's system monitor tells me that firefox-bin is consuming 99.2MB of resident memory and 277.6MB of virtual memory.  Xorg is also consuming a similar amount of virtual memory, and the memory consumption has only been consistently this bad in Ubuntu 6.10 and 7.04, and not in 6.06 (if I recall).  Perhaps my problems are related to Xorg and not jut Firefox.
I've found Seamonkey version - Bug 361852.
Depends on: 361852, 376476
(In reply to comment #51)
> I see that there are only 2 bugs that depend on this (part of the campaign),
> however there are bugs out there that should be added here. Example is bug #
> 341872, which even has a patch attached. are there plans to search for and
> include more memory leak bugs to this campaign? I hope so -thanks. 

I think main objective of this meta bug is "rule out of false/invalid reports which shout 'memory leak!'", because this bug's summary is "leak campaign".
  - Rule out real leak by extension(add-on)
  - Rule out invalid bugs due to larger real/virtaul memory size report
    than user's expectation or (wrong) conviction.
  - Find real leak problem involved in bug who shouts "memory leak!".
  - Rule out problem explained in Bug 381950 on MS Win
    when config.trim_on_minimize=false (defaulted since Fx/Tb 1.5)

Followings are recently opened real(valid) leak bugs which are detected by leak gauge tool or are discovered by use of XPCOM logging facilities. 
( http://www.mozilla.org/performance/leak-tutorial.html )
> Bug 381992 thunderbird leaks a jscontext
> Bug 383939 RDF datasources must implement cycle collection to avoid leaking
> Bug 385376 Memory leak when closing a tab?
> Bug 388353 Displaying a Mail Messages leaks a jsContext & a global window
> Bug 389594 Loading a saved Search Folder that searches Multiple Folder leaks nsGlobalWindow

And there are only 4 meta bugs which have "leak" in summary. 
> Bug  37445 service objects should be release ASAP to reduce footprint & memory leaks
> Bug 205821 Mozilla using wrong files after profile switch, causing information leaks
> Bug 157937 PSM leaks tracking bug
> Bug 320915 [Meta] 1.8 memory leak campaign

To towsonu2003@gmail.com:  
I think you'd better to open and own new tracking bug(meta bug) for real/valid memory/resource leak bugs.
Two newbies for Firefox I recently found: Bug 370202, Bug 392297.
Depends on: 370202, 392297
Should this bug not be closed (WFM or WONT)? The 1.8 branch has been in security-fix-mode for quite a while now. If anyone plans to address the dependent bugs which are still open he should probably open a new meta bug for Gecko 1.9 (too late, too?) or Mozilla2.
(In reply to comment #59)
> Should this bug not be closed (WFM or WONT)?

Bug 434217 is a newbie of Thunderbird I found recently.
I believe close of this bug is too early. Close of this bug should be done after official release of all of Fx 3/Tb 3/Sm 2 and after closing of all bugs listed in dependency tree for this bug as INCOMPLETE.

To Peter Weilbacher:
Could you please open meta bug of "[Meta] 1.9 memory leak campaign"?
Because beta testing for Fx 3.0 is already started, I think meta bug which is successor of this bug will be required, in order to close this bug after release of Fx 3/Tb 3/Sm 2.
Depends on: 434217
No longer depends on: 376476
No longer depends on: 369255
No longer depends on: 378077
No longer depends on: 381950
No longer depends on: 434217
(In reply to comment #60)
> Bug 434217 is a newbie of Thunderbird I found recently.
> I believe close of this bug is too early. Close of this bug should be done
> after official release of all of Fx 3/Tb 3/Sm 2 and after closing of all bugs
> listed in dependency tree for this bug as INCOMPLETE.

As this bug was about Gecko 1.8 and not about MailNews core that is shared by TB and SM it makes little sense to keep adding TB bugs here. All those product are in security maintenance and none of the potential leak bugs will be solved there. So I removed the unnecessary dependencies. All blocking bugs are now closed/fixed, so this can be fixed, too.

> To Peter Weilbacher:
> Could you please open meta bug of "[Meta] 1.9 memory leak campaign"?
> Because beta testing for Fx 3.0 is already started, I think meta bug which is
> successor of this bug will be required, in order to close this bug after
> release of Fx 3/Tb 3/Sm 2.

I don't really see the point any more for a Gecko 1.9. The big memory campaign lead to the use of jemalloc on the main platforms and was fairly successful without such a bug. If the main developers of MoMo want to open such a bug for Thunderbird and SeaMonkey, they can do so on their own, I guess.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: