User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3) Gecko/20070322 Firefox/1.5 Build Identifier: Thunderbird 2.0.0.0 (20070326) Memory consumption is incredibly high and keeps increasing. For example, right now: 10883 stefan 15 0 480m 357m 20m S 0.0 49.4 2:30.30 thunderbird-bin I already had the same problem with RC1. Earlier versions (1.5.*) seemed to be ok, though. I am unable to identify a specific action or component that causes the problem. Might be that the memory is leaking in the background process that periodically checks my POP account, as memory consumption increases even when I don't do anything with Thunderbird. Reproducible: Always Steps to Reproduce: 1. Start Thunderbird. 2. Leave it running for a few hours. Actual Results: 10883 stefan 15 0 490m 368m 20m S 0.0 50.9 2:31.23 thunderbird-bin

Same comment as Bug 320915 Comment #28. (Please read thru Bug 320915. Many are on MS Win, but some are applicable to Linux too.) Questions: Can you observe memory use status for each hour or each 30 minutes from start of Thunderbird? Problem can be re-created with new profile/no extension/standard theme? Can you check difference of behavior from latest-trunk nightly?

Thunderbird version 1.5.0.10 (20070221) Microsoft Windows XP SP1 I have the same problem. Start Thunderbird, leave it for a day, come back and find it has taken up huge amounts of memory. (My work machine only has 128mb, so it's pretty significant). I have three accounts running and on all accounts I have an 'Old' folder that I move old files to. The second account has 1829 emails in the old folder. When I looked with Process Explorer, I saw that Thunderbird has 166 handles open to this mailbox. (See included screenshot). I think this might be a clue to the heavy memory usage. The rest of the mailboxes had only a single file handler open. Unknown if it effects the problem: - 'Check mail messages for email scams' is on - 'Allow anti-virus clients to quarantine individual messages' is off - For this account: "Check for new messages every 10 minutes" - "Automatically download new messages" is on - All folders have a spam junk folder - When I clicked the old folder to check the number of messages, it said "Building summary file" before showing me the messages. Running extensions: - Talkback 1.5.0.10 - Enigmail 0.94.1.2 - MinimizeToTray 0.0.1.2006102615+

(In reply to comment #2) > I have the same problem. Start Thunderbird, leave it for a day, come back and > find it has taken up huge amounts of memory. (My work machine only has 128mb, > so it's pretty significant). > - Enigmail 0.94.1.2 > - MinimizeToTray 0.0.1.2006102615+ To Ren Hoek: Have you read Bug 320915? Please read at least Bug 320915 Comment #28, Bug 320915 Comment #42 and Bug 320915 Comment #46. Key questions to you ; (Q1) Is problem recreated with new profile? How about when newest trunk build? (Q2) Are you talking about real memory size or virtual memory size? (Q3) If real memory, can config.trim_on_minimize=true be a workaround? > When I clicked the old folder to check the number of messages, > it said "Building summary file" before showing me the messages. Read http://kb.mozillazine.org/Keep_it_working_%28Thunderbird%29 , and get the "Building summary file" completed first. Will "Building summary file" occur frequently even after some actions recommended by "Keep it working - Thunderbird"?

(In reply to comment #4) > To Ren Hoek: Have you read Bug 320915? > Please read at least Bug 320915 Comment #28, Bug 320915 Comment #42 and Bug > 320915 Comment #46. Ok, the memory leak tool you refer to in #28 seems to be targetted at Firefox, not Thunderbird. If there is someway I can give better info for Thunderbird, feel free to tell me how. #42 & $46 concerning "config.trim_on_minimize=true", if there is a about:config in Thunderbird, then I haven't found it yet. > Key questions to you ; > (Q1) Is problem recreated with new profile? How about when newest trunk build? > (Q2) Are you talking about real memory size or virtual memory size? > (Q3) If real memory, can config.trim_on_minimize=true be a workaround? 1) I have three accounts configured in Thunderbird. Thunderbird eats up memory, how am I able to determine which profile it at fault? Also, what is a trunk build and where can I find one. 2) I'm talking about real memory (see the screenshot, "private bytes"). So this is what TB takes for himself, without the DLL's or any other shared codebase that might be in memory. 3) Please tell me how to configure this. > > > When I clicked the old folder to check the number of messages, > > it said "Building summary file" before showing me the messages. > > Read http://kb.mozillazine.org/Keep_it_working_%28Thunderbird%29 , and get the > "Building summary file" completed first. > Will "Building summary file" occur frequently even after some actions > recommended by "Keep it working - Thunderbird"? > I will keep track of this. Just a note in general. I can understand that as a programmer (I am one too) you want as much information as possible to narrow down the problem. I myself know the hell "recreating bugs" can be. However I am completely unfamiliar with the internals of both Firefox and Thunderbird, and consider myself lucky I even know how to tweak FF with "about:config". You, the programmers of FF and TB and those who are deeply familiar with the code, should realize that you are not making it easy on us laymen to help you. You ask things of which I have no notion and point at articles that are hard to understand. The talkback agent, which automatically send all the relevant information on crashes, must have given you a wealth of relevant information without the user having to know/do a lot of the internals. Wouldn't it be easier if there was some kind of option under "Help" like "Generate debug report" that would automatically index all of the information that you needed? A technique I use sometimes myself, of which I have no clue if you are using as FF/TB programmers, is a making a simple lib that keeps track of all the allocated/freed memory. A simple push of the button would create a list of all the memory in use. Might I suggest implementing something like that in standard builds? Then in the future I could simply zip up and send in a list?

leak logs for gecko tend to be amazingly large. and practically speaking average users like to do lots of things and would give us amazingly long logs which aren't really helpful. if you're curious, you can read http://www.mozilla.org/projects/xpcom/MemoryTools.html build w/ enable flags for the relevant bits and try turning on the logging. note that for instance turning on refcounting for all objects will result in the application never opening its first window (it's that slow). in theory we could autotune so that people could run the program once, have it record which things leaked, and then be prompted with a list and asked which one(s) they'd like to chase, and then have it run again. but mostly, we leave such leak tracking to developers. google: thunderbird about config yields: http://www.mozilla.org/support/thunderbird/edit which is about:conofig. put another way, you probably don't want to try analyzing the behavior of a gecko whose process has passed 100mb (or 50mb for that matter). By the time it's gone that far, there are way too many variables, steps, and too much time which would be exasperated by trying to use any of these tools. if you're on windows, there's /sometimes/ a debug build available as a link from http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg which would enable you to skip the build process. as for private bytes, we're at the mercy of the cruntimes, which i believe we believe tend not to release pages on average. i can't find a handy way to explain this, but consider this code: void** allocChain(int n) { void *w=0; if (n>0) w=allocChain(n-1); void *x=malloc(3000); void **y=malloc(1); if (!y) { freeChain(w); return 0; } if (x) free(x); *y=w; return y; } void freeChain(void** y) { if (!y) return; if (*y) freeChain(*y); free(y); } Imagine we call allocChain(1000) once and haven't yet called freeChain() on its result, we've allocated approximately 1000 bytes. but the actual size that the runtime will see is probably a lot closer to 3m. and it will remain that way until the chain is freed. - Note that my example isn't tested, there are various interesting features of the runtime which will influence the results (partly it depends on whether my magic numbers are correct and whether i've properly filled my buckets). Note that the os will probably report things as a multiple of 4096 bytes or some similar number because of allocation sizes and overhead from the crt). now, the actual way this happens tends to not quite match my example, but oh well. you get what you pay for (and you didn't pay for this bad example). one thing that i don't think anyone has played with is SWS, http://msdn.microsoft.com/msdnmag/issues/1200/bugslayer/ I'd suggest that instead of you making suggestions you actually look at what we have available and try playing with them. when you realize how many tools we have and how complicated/powerful they are, maybe you'll make better/more informed suggestions (or just not make suggestions, that's up to you).

(In reply to comment #5) > the memory leak tool you refer to in #28 seems to be targetted at Firefox, > not Thunderbird. You are right, but it is sometimes applicable to Tb too, because "viewing a mail" is internally/roughly similar to "open a tab and load an URL into tab", although it's not so powerfull when Tb and not so many memory leak can be detected by this tool when Tb. > #42 & $46 concerning "config.trim_on_minimize=true", if there is a about:config > in Thunderbird, then I haven't found it yet. Tb version of "about:config" is Tools/Options/Advanced/general tab/Config Editor. config.trim_on_minimize is not displayed in Config Editor is it is not set. Put next line in user.js, and restart Tb. user_pref("config.trim_on_minimize", true); If you feel config.trim_on_minimize=false is better than true for you, delete above line from user.js and reset it(toggle) thru config editor, and restart Tb. > 2) I'm talking about real memory (see the screenshot, "private bytes"). Please watch also equivalence to "Virtual Memory Size" of MS Win's Task Manger by your tool.

i confirm this, TB 2.0.0.0 leaking memory. here's what i get from html/javascript that handles NSPR logs (this information appears only after closing TB): Leaked outer window 1eceda0 at address 1eceda0. Leaked inner window 1ee7008 (outer 1eceda0) at address 1ee7008. ... with URI "about:blank". Summary: Leaked 2 out of 13 DOM Windows Leaked 0 out of 51 documents Leaked 0 out of 6 docshells this was done with my old profile, no addons installed (actually all of them removed, i was thinking that it's addons failing somehow), i have this profile since 1.5. should i create new account and check, or i'm done debugging for now and this output is any kind of helpful? :)

(In reply to comment #8) > i confirm this, TB 2.0.0.0 leaking memory. > Leaked inner window 1ee7008 (outer 1eceda0) at address 1ee7008. > ... with URI "about:blank". > Leaked 2 out of 13 DOM Windows Thanks for test with leak gauge. I saw some bugs who say "leak when about:blank", I can't recall bug no. though. If the leak is also reported by trunk nightly(with new profile), please open new bug for the leak after searching bugzilla.mozilla.org for already opened/duped/fixed bugs well. Note: Trunk builds seem to have some severe problems from a build around 5/22. When you test for the leak with trunk, and if severe problems are encountered, try to use builds before 5/20.

(In reply to comment #3) > Screenshot of process explorer showing file handles I saw a comment about "leave db's open for folders" in Bug 329569 comment #7. See Bug 329569 comment #28 also. To Ren Hoek: If "too many file handles for an .msf file" can be recreated with trunk nightly (with new profile), please open new bug for the problem, with sufficient data for problem analysis (Process Monitor log, NSPR log, Junk log and so ons), after searching bugzilla.mozilla.org for already opened/duped/fixed bugs well.

I have been unable to reproduce the bug. Seems like the rebuilding fixed the huge folder. No longer will hundreds of those db files remain open. If I encounter it again I'll let you know.

(In reply to comment #9) > (In reply to comment #8) > > i confirm this, TB 2.0.0.0 leaking memory. > > Leaked inner window 1ee7008 (outer 1eceda0) at address 1ee7008. > > ... with URI "about:blank". > > Leaked 2 out of 13 DOM Windows > > Thanks for test with leak gauge. > I saw some bugs who say "leak when about:blank", I can't recall bug no. though. > If the leak is also reported by trunk nightly(with new profile), please open > new bug for the leak after searching bugzilla.mozilla.org for already > opened/duped/fixed bugs well. > Note: Trunk builds seem to have some severe problems from a build around 5/22. > When you test for the leak with trunk, and if severe problems are encountered, > try to use builds before 5/20. i've installed 5/24 build in a new user environment, i'm a little confused - when i run TB and leaks gauge.html in firefox (2.0.0.3), then parse nspr.log i see this: Leaked outer window 1eb9468 at address 1eb9468. Leaked inner window 1779ee8 (outer 1eb9468) at address 1779ee8. ... with URI "about:blank". Leaked outer window 17ad718 at address 17ad718. Leaked inner window 24cab78 (outer 17ad718) at address 24cab78. ... with URI "about:blank". Leaked outer window 2812538 at address 2812538. Leaked outer window 2766800 at address 2766800. Leaked inner window 387eaa0 (outer 2812538) at address 387eaa0. ... with URI "chrome://messenger/content/msgAccountCentral.xul". Leaked outer window 38abf90 at address 38abf90. Leaked inner window 3956598 (outer 38abf90) at address 3956598. ... with URI "about:blank". Leaked inner window 255d178 (outer 2766800) at address 255d178. ... with URI "news://ddt.demos.su:119/1179845342%40p50.f8.n5093.z2.ftn". Leaked outer window 2ceb8a0 at address 2ceb8a0. Leaked inner window 2ae5b88 (outer 2ceb8a0) at address 2ae5b88. ... with URI "about:blank". Leaked document at address 253ff98. ... with URI "file:///C:/Program%20Files/TB_pre/res/hiddenWindow.html". ... with URI "resource://gre/res/hiddenWindow.html". Leaked document at address 256d178. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/scrollbar.xml". ... with URI "chrome://global/content/bindings/scrollbar.xml". Leaked document at address 1e37468. Leaked document at address 26157c0. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/general.xml". ... with URI "chrome://global/content/bindings/general.xml". Leaked document at address 26c3b30. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/browser.xml". ... with URI "chrome://global/content/bindings/browser.xml". Leaked document at address 26e3200. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/popup.xml". ... with URI "chrome://global/content/bindings/popup.xml". Leaked document at address 2757500. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/text.xml". ... with URI "chrome://global/content/bindings/text.xml". Leaked document at address 2781cf8. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/stringbundle.xml". ... with URI "chrome://global/content/bindings/stringbundle.xml". Leaked document at address 2760650. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/messenger.jar!/content/messenger/mailWidgets.xml". ... with URI "chrome://messenger/content/mailWidgets.xml". Leaked document at address 275bac0. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/toolbar.xml". ... with URI "chrome://global/content/bindings/toolbar.xml". Leaked document at address 2786a10. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/menu.xml". ... with URI "chrome://global/content/bindings/menu.xml". Leaked document at address 27843c0. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/toolbarbutton.xml". ... with URI "chrome://global/content/bindings/toolbarbutton.xml". Leaked document at address 27d6008. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/button.xml". ... with URI "chrome://global/content/bindings/button.xml". Leaked document at address 27d7180. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/tree.xml". ... with URI "chrome://global/content/bindings/tree.xml". Leaked document at address 280a618. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/splitter.xml". ... with URI "chrome://global/content/bindings/splitter.xml". Leaked document at address 27f74a0. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/textbox.xml". ... with URI "chrome://global/content/bindings/textbox.xml". Leaked document at address 284e900. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/platformHTMLBindings.xml". ... with URI "chrome://global/content/platformHTMLBindings.xml". Leaked document at address 2866c18. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/messenger.jar!/content/messenger/search.xml". ... with URI "chrome://messenger/content/search.xml". Leaked document at address 2764be0. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/findbar.xml". ... with URI "chrome://global/content/bindings/findbar.xml". Leaked document at address 3796288. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/progressmeter.xml". ... with URI "chrome://global/content/bindings/progressmeter.xml". Leaked document at address 2619ff8. Leaked document at address 3964dd0. Leaked document at address 3810f68. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/dialog.xml". ... with URI "chrome://global/content/bindings/dialog.xml". Leaked document at address 397f510. ... with URI "jar:file:///C:/Program%20Files/TB_pre/chrome/toolkit.jar!/content/global/bindings/checkbox.xml". ... with URI "chrome://global/content/bindings/checkbox.xml". Leaked document at address 38e7970. ... with URI "news://ddt.demos.su:119/1179845342%40p50.f8.n5093.z2.ftn". Leaked document at address 2bee000. Leaked docshell at address 1e7ec30. ... which loaded URI "resource://gre/res/hiddenWindow.html". ... which loaded URI "about:blank". Leaked docshell at address 24d5a20. ... which loaded URI "chrome://messenger/content/messenger.xul". ... which loaded URI "about:blank". Leaked docshell at address 2812008. ... which loaded URI "about:blank". ... which loaded URI "chrome://messenger/content/msgAccountCentral.xul". Leaked docshell at address 28bfd40. ... which loaded URI "about:blank". ... which loaded URI "chrome://messenger/content/start.xhtml". ... which loaded URI "news://ddt.demos.su/1179775128%40p50.f8.n5093.z2.ftn". ... which loaded URI "news://ddt.demos.su:119/1179775128%40p50.f8.n5093.z2.ftn". ... which loaded URI "news://ddt.demos.su/1179826890%40p178.f23.n5012.z2.ftn". ... which loaded URI "news://ddt.demos.su:119/1179826890%40p178.f23.n5012.z2.ftn". ... which loaded URI "news://ddt.demos.su/1179845342%40p50.f8.n5093.z2.ftn". ... which loaded URI "news://ddt.demos.su:119/1179845342%40p50.f8.n5093.z2.ftn". Summary: Leaked 12 out of 17 DOM Windows Leaked 26 out of 35 documents Leaked 4 out of 6 docshells although under my user firefox was not affected.

i've deinstalled TB build, but now leaking gauge always showing me the same picture - a lot of leakage everywhere! under any user, with old and with new profile... what i may have done wrong?

after deinstalling firefox and TB and reinstalling them (all 2.0 version) leaking gauge continue showing me leakage from everywhere: Summary: Leaked 12 out of 24 DOM Windows Leaked 30 out of 48 documents Leaked 4 out of 8 docshells

First, dont't paste long data to bug, attach file to this bug instead. > i'm a little confused - when i run TB and leaks gauge.html in firefox > (2.0.0.3), then parse nspr.log i see this: alexander, did you run gauge.html after shutdown of Thunderbird? > i've deinstalled TB build You don't need to use installer build. If MS Win, use ZIP build. You can test by unzipping only.

(In reply to comment #15) > First, dont't paste long data to bug, attach file to this bug instead. > > > i'm a little confused - when i run TB and leaks gauge.html in firefox > > (2.0.0.3), then parse nspr.log i see this: > > alexander, did you run gauge.html after shutdown of Thunderbird? oh, i forgot that :) now i have the same "about:blank" Leaked inner window 2213ab0 (outer 2212af0) at address 2213ab0. ... with URI "about:blank". Leaked outer window 2212af0 at address 2212af0. Summary: Leaked 2 out of 35 DOM Windows Leaked 0 out of 120 documents Leaked 0 out of 8 docshells > > i've deinstalled TB build > > You don't need to use installer build. If MS Win, use ZIP build. You can test > by unzipping only. could you point me to zip build? i don't really understand which one i need.

> could you point me to zip build? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ Go http://www.mozilla.org/developer/ and read documents, please.

(In reply to comment #17) > > could you point me to zip build? > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ > Go http://www.mozilla.org/developer/ and read documents, please. > oh, i see. in the first time i tried to download nightly-build from /developer/ section. i get 404 on file and then i start digging ftp :) ok, i ran this build and leakage is still there: Leaked outer window 200d310 at address 200d310. Leaked inner window 208fd98 (outer 200d310) at address 208fd98. ... with URI "about:blank". Summary: Leaked 2 out of 8 DOM Windows Leaked 0 out of 24 documents Leaked 0 out of 4 docshells

Following is bugs I picked up from my quick search result of "open, summary contains leak, comment contains about:blank, updated in these 3 months". - Bug 39238, Bug 341447, Bug 380837 Symptom of Bug 380837(2 nsGlobalWindows are leaked) looks to be similar to your result, although this is bug report on Mac OS X. Please open new bug, with attaching NSPR log data file.

(In reply to comment #19) > Following is bugs I picked up from my quick search result of "open, summary > contains leak, comment contains about:blank, updated in these 3 months". > - Bug 39238, Bug 341447, Bug 380837 > Symptom of Bug 380837(2 nsGlobalWindows are leaked) looks to be similar to your > result, although this is bug report on Mac OS X. > Please open new bug, with attaching NSPR log data file. I filed a Bug 381992

>I filed a Bug 381992 To alexander: "in my case working set grows up to 212MB"(displayed real memory size which MS WIndows considers Tb uses) is different from "grow's up to end of virtual memory", and is different problem from the suspected memory leak problem. Even if "memory leak of about:blank" really exists, I believe "(infinite) increase of virtual memory size used by TB due to this suspected memory leak" is not observed externally. See Bug 381950 Comment #0 and read pages pointed by it, please.

(In reply to comment #21) > >I filed a Bug 381992 > > To alexander: > "in my case working set grows up to 212MB"(displayed real memory size which MS > WIndows considers Tb uses) is different from "grow's up to end of virtual > memory", and is different problem from the suspected memory leak problem. > Even if "memory leak of about:blank" really exists, I believe "(infinite) > increase of virtual memory size used by TB due to this suspected memory leak" > is not observed externally. > See Bug 381950 Comment #0 and read pages pointed by it, please. yes, it is grows up to 212MB (i see that) and yes i think that "end of virtual memory" error is occurred because of TB eating all memory - isn't it logical explanation? what do you want from me, really? i'm not developer of TB, i'm just a user. i gave you all info i could. and why i need to read about how windows manages memory - will it change something?

(In reply to comment #22) > what do you want from me, really? Simply following. - At least to distinguish "real memory" and "virtual memory", and to understand difference between them. > why i need to read about how windows manages memory - will it change something? (1) The document will help you to understand "real memory" and "virtual memory". (2) The document will help to understand why number displayed in "Memory Usage" column by MS Win's Task Manager grows when config.trim_on_minimize=false is used by Seamonkey/Firefox/Thunderbird. Note: This is the reason why I opened Bug 381950. (3) (1) & (2) will help you to understand that the "leak reported by gauge.html for about:blank" is completely different problem from "growth of number displayed in Memory Usage column".

After I turned off RSS feeds, the problem disappeared. Resident set now stays consistently around 50 MB.

(In reply to comment #24) > After I turned off RSS feeds, the problem disappeared. Resident set now stays > consistently around 50 MB. Which OS? MS Win / Linux / Mac OS X Was rapid "virtual memory size growth" observed in addition to "Resident set growth" when RSS feeds were turned on?

(In reply to comment #25) > (In reply to comment #24) > > After I turned off RSS feeds, the problem disappeared. Resident set now stays > > consistently around 50 MB. > > Which OS? MS Win / Linux / Mac OS X Scroll to the very top of this bug to find the desired information. > Was rapid "virtual memory size growth" observed in addition to "Resident set > growth" when RSS feeds were turned on? I fail to see how the resident set could grow beyond the virtual address space. Also, scroll to top of bug to see VIRT=480m, RES=357m in my first description. In comparison, I now have VIRT=155m, RES=56m after having TB running for almost an hour. This is much more tolerable than before.

(In reply to comment #26) > Scroll to the very top of this bug Oh, you are the bug opener. Sorry for my forgetting bug opener's name. Although "larger memory size" only can not be evidence of memory leak, something wrong in RSS is suspected, because next document leak is reported by alexander to Bug 381992 Comment #2 (With mail viewing, I can't produce this document leak.) > Leaked document at address 39674c8 ... with URI "http://bash.org.ru/rss/".

Ren Hoek, Alexandar - do you also have RSS feeds? What is the update frequency?

(In reply to comment #28) > Ren Hoek, Alexandar - do you also have RSS feeds? What is the update > frequency? I HAD RSS feeds with 10 minutes update frequency, but now i'm using Sage Firefox extension since TB 2.0.0.0 fail to add new feeds. And i am very disappointed about this, so now i'm using TB only as mail user agent and news reader. I liked RSS reader in TB, but there always were some kind of failures in it. I was unable to add good RSS feeds for TB thinks they're bad. From time to time on different channels old news appeared. Now, in 2.0.0.0, i can't add another feed. If i'll stumble upon some free featurefull mail/news/RSS reader, i'll stop using TB, for it is oh so buggy and not user-friendly :( Why, tell me, if i want to import unix mailbox, i have to copy file to my profile (in hidden folder!) - why not import it through menu Tools/Import? Why i can't "export"? And there are many more such little distracting things. Sorry about last paragraph, but i have to say this.

(In reply to comment #28) > Ren Hoek, Alexandar - do you also have RSS feeds? What is the update > frequency? > I'm not using any RSS at all. But I suspect my problem had to do with unbuild/corrupt mail folders, which is why the problem did not return after rebuilding them. So I believe the problem I had was very specific.

"Leak by RSS" is being processed by Bug 385178.

David, Wada - does thunderbird use the same RSS feed code as firefox in bug 385178 mozilla/browser/components/feeds/src/FeedConverter.js, etc.? If so, perhaps Stefan could try a trunk build of thunderbird and report back here if problem is solved when for 385178 checks in (should be soon). Alexander, until this is fixed you might inrease the update frequency. 10 minutes is very short, especially if you only read a few times a day, or have feeds that don't update very often. increasing to 100 minutes for example should get you a 10-fold reduction in memory increase. Has anyone quantified the RSS memory usage in thunderbird? Using "get new messages" I get anywhere from 0 to 1 MB with 30 feeds, but I'm not sure the automatic process would experience the same usage.

Stefan, You wrote me that increasing RSS check frequency resolved your issue. At what value did the problem go away? And using a newer version of 2.x, if you decrease check frequency to a value that previously caused problems does the problem come back ? Also is problem better or worse with current trunk build (comment 17)? (bug 385178 is fixed on trunk)

reporter writes "I am not using trunk any more, and I am not sure whether I will have time in the near future to install it and test whether the problem still exists."

TB 2.x is in security maintenance mode, so this is not going to get resolved for 2.x. Therefore clearing dependency on Gecko 1.8 bug.

stefan, please recheck after tb3.0b2 is out ~mid-late february http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ or try beta 1 which is recently out

given comment 34, works for me, and likely fixed in current beta/trunk, closing WFM. Stefan, if you see this with thunderbird 3 please reopen the bug. Others, please file a new bug and refer to this one. https://developer.mozilla.org/en/Thunderbird/Thunderbird_Binaries