Closed Bug 340260 Opened 19 years ago Closed 18 years ago

Huge memory leak after 20060509 nightly (threadmanager checkin) in seamonkey browser and thunderbird - NOT f l a s h

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 342810

People

(Reporter: ezh, Unassigned)

References

(
URL
)

Details

(Keywords: memory-leak, regression, Whiteboard: [need testcase] DO NOT REPORT FLASH PROBLEMS HERE)

Attachments

(4 files)

Huge memory usage of Seamonkey 1.5a1 after some hours of usage
49.77 KB, image/png
Details
Huge memory usage of Thunderbird 3.0a1 after some hours of usage
48.06 KB, image/png
Details
screenshots
55.09 KB, image/png
Details
070115 Seamonkey
299.22 KB, image/jpeg
Details
Between 20060509 and 20060512 Mozilla products start to eat off all memory on my system. The Seamonkey 1.5a1 20060509 was as usual - 80-100Mb after a 12 hours of usage. I found that the next available Seamonkey build of 20060512 is using huge memory amount - 300, 400 and more after some time (It may be 1 hour, depending of activity). The same goes to Thunderbird 3.0a1 I'm using, but I had not tested what build started to behave so. I believe this was the time frame of new treat manager check-in. I'll attach a screenshot of taskmanager. Should I open the same bug for TB (I could try FF also)?
Attachment #224324 - Attachment description: Huge memory usage of Seamonkey after some hours of usage → Huge memory usage of Seamonkey 1.5a1 after some hours of usage
I'm unsure of the date it started happening, but I am also seeing enormous memory usage now. Not unusual to see 800 MB of RAM allocated to the Thunderbird.exe process after several hours of usage...
I'm using Seamonkey only for browsing, I'm even not installing the Mail component.
Can you narrow it down further than 3 days?
There is no builds... The only available are: Windows binaries: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-09-10-trunk/ - works fine Started eating up memory (both): http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-12-08-trunk/ http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-12-10-trunk/ So, it happened between 2006-05-09-10 and 2006-05-12-08. I could test TB builds, but they are not on the ftp amymore.
I see the same situation on my computer at work, as today I installed the 2006060508 build. And BTW when I close the 300+ Mb Seamonkey in does not goes away from the processes - I need to close it by "End Task", if that's information helps. The Thunderbird 20060510 2.0a1 (the branch build!) installed on this computer is fine. Both are Athlon 3200+ (o'clocked 2500+) with Windows XP Home installed.
(In reply to comment #8) > Both are Athlon 3200+ (o'clocked 2500+) with Windows XP Home installed. Could you stop overclocking and verify that you still see the issue?
They are rock solid even in games and how the overclocking may hurt the memory usage after some builds?
Doesn't matter, it should still be elimiated from the possible causes.
The problem to do with the Seamonkey process not closing when the front end is closed should be taken to another bug report. This bug report was opened with the description and obviously the intention of looking at high memory usage, and not the application not closing. The app may well use lots of memory too, which we need to get to the bottom of. I would think it would be a separate issue.. I am seeing exceptionally high memory usage over time with Thunderbird but don't have any problem with the application shutting down. My system is a 2.8D processor with 2G DRAM, and is definitely _not_ overclocked.
The application does not close when it uses huge amount of memory. When I open Seamonkey and 10 minutes after close it it closes well for me.
I found the builds archive http://archive.mozilla.org/pub/thunderbird/nightly/. Installed TB 3.0a1 2006051008 - it seems to be fine.
It seems, that Tb 2006050908 is affected be the leak. I'll check the TB 3.0a1 2006051008 once more.
TB 20060508 (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-08-06-trunk/) uses 96Mb after almost 20 hours of usage. The next Tb 2006050908 (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-09-06-trunk/) uses much more memory. But the 2006050908 Seamonkey build (the build number is from the about dialog) uses the common memory amount. Strange. Looks like the Tb and Seamonkey trunk are not syncronized? Could anyone check the check-ins in that timeframe?
A cursory look shows a closed tree - almost nothing acutally got checked in between 2006-05-08 00:00:00 and 2006-05-06 06:00:00. Bug 337020 did land, but wouldn't only affect Thunderbird.
URL: http://bonsai.mozilla.org/cvsquery.cg...
cst@yecc.com, could the build time on ftp folder show the actuially not the building time but appearing on the ftp? The Seamonkey folder on ftp is http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-09-10-trunk/
The http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2006-05-09-10-trunk/ is _NOT_ affected for me. It shows 120Mb after 20 hours 120Mb of mem usage, what is normal for Seamonkey.
BTW. When I close Seamonkey after some time of isage it crashes on exit: TB19762701G, TB19747186Q
(In reply to comment #18) > cst@yecc.com, could the build time on ftp folder show the actuially not the > building time but appearing on the ftp? Yes. My query ran from 6 hours before the time you gave, until the time you gave, which I think is a reasonable margin.
comment 20 is probably bug 318357 if your library matches the unhappy one from that bug, please follow the link for TB19762701G and paste it (starting with the blue line that says "Incident ID:") into that bug. if not, please file a bug against opensc as the bug is almost certainly not actually in nss *AND* another bug against nss/libraries with the contents of that (again starting from "Incident ID:") into your new bug with a reference to the opensc bug report.
Unfortunately I can't help narrow down the timeline at all either, but I can confirm this on multiple machines running Windows XP Pro. (2 Intel Pentium D 830's and a Pentium 4 3.2ghz. 1 Pentium 830 has 2GB RAM, the others have 1 GB. None are overclocked) After about 2-3 hours of use on my machines, SeaMonkey starts taking up tons of RAM. Something does seem to trigger it, though, as it is random. I have Quick Start enabled, and I have to completely close Seamonkey for it to release the RAM. (just closing all windows doesn't help) I use Seamonkey only for browsing, not for mail or chat or HTML editing. Maybe it's related to the UI, since it seems to be affecting other Mozilla products? It does not seem to be related to any specific browsing habit (tons of open tabs, Flash, etc), it's more time related and takes time to trigger. Are there any extensions or options that could be useful for data on this?
Thunderbird 2006062004. After about 1.5 hours TB uses 295Mb RAM and 285Mb VM. Does anyone started investigation?
Assignee: general → nobody
Product: Mozilla Application Suite → Core
QA Contact: general → general
Summary: Huge memory leak → Huge memory leak (in mail?)
Flags: blocking1.9a1+
Depends on: 341430
Boris, I see this happens in Seamonkey and Thunderbird. And I do not use Gmail at all, so bug 341430 is not related.
Summary: Huge memory leak (in mail?) → Huge memory leak
After about 3 hours uptime in SM win32 trunk 2006070909 with one tab in one browser window and 5 tabs in one CZ window I see use of only 52M, compared to 29M for FF 1.5.0.4. IOW, WFM.
What OS, what processor are you using? After 1.5 hours of using Tb 3.0a 2006071003 (not intensive usage) it uses for me 129500Kb in mem and 114650Kb in VM. That was 21.30 local time. I have the taskbar open and TB gets new mail. After the sound of recieving new mail the mem amount already is 134420Kb and 116000Kb in VM. 21.45 local time. After browsing thrue mail boxes and composing mail it uses now: 153130Kb abd 138580Kb VM. I'll try it on my Centrino Pentium-M notebook.
(In reply to comment #27) > What OS, what processor are you using? XP on PIII-700 w/ 384M RAM
I installed Seamonkey 2006071009 1.5a, opened 2-3 pages in 2 windows and go to sleep. Today at the morning it shows 265000Kb in mem and 903500 in VM. After opening 2 new SM windows (it took 3-4 minute and massive HDD usage) it grew to 356500Kb + 913250Kb in VM. I did screenshots. The upper one is after I get to the computer and the lower is after opening to windows + reading 2 mail in Tb. Now I have only 1 window with bugzilla open (here I'm writing this report) and every second Dm mem usage grows for 20Kb and sometimes in adds 12 or 16Kb. Maybe I could make some leak test or whatever? AMD 2500+ (o'c 3200+), 1Gb RAM.
Attached image screenshots —
(In reply to comment #29) > Maybe I could make some leak test or whatever? > > AMD 2500+ (o'c 3200+), 1Gb RAM. > Sure, but please don't overclock when you're doing the testing.
What's the point in not overclocking when overclocked all works just fine and SM, TB and FF worked also fine?
What's the point in not overclocking when overclocked all works just fine and SM, TB and FF used to work also fine? I repeat: the 20060509 builds are last fine working builds.
There is obviously something going on, some trend, that makes it so you either see this bug or you don't. I see it every day in the course of normal use of Seamonkey. Usually goes to around 300,000-400,000kb used in VM after about 3-4 hours before I have to restart Seamonkey (which does allow it to flush and all is ok for a while). Maybe it has to do with Flash or some other external component not playing well with something in Gecko? (since this is being seen in Firefox, TB, Seamonkey, etc)
Justin Scott, do you use Thunderbird as well? Tb does not shows Flash and uses as much as latest Seamonkey does...
Marking blocking1.9? since there doesn't seem to be enough information here to mark blocking1.9+.
Flags: blocking1.9?
Observation of "Virtual Memory Size" by Task Manager. - MS Win 2K, SeaMonkey 2006070409 - Multiple POP3 accounts, No IMAP connection(Dummy IMAP definition), Some News (1) Get All New Messages "Virtual Memory Size" increases on every Get All New Messages. (2) Repeated Get Messages to an account "Virtual Memory Size" does not increase on any repeated Get Messages. (3) Switching of account and Get Messages "Virtual Memory Size" increases on first Get Messages after account switch. Even no manual operation at Mail&News, automatic download by "Every NN minutes" is usually executed, and (3) may occur. (3) seems to be involved in infinite memory usage increase. See Bug 329876 for infinite memory increase by manual operation. (This is not new phenomenon after 20050509 build)
I do not use Seamonkey as my mail client.
(In reply to comment #38) > I do not use Seamonkey as my mail client. I've understood that your Comment #29 is for Browser only SeaMonkey(no mail&news is installed), and that Mail&News related memory size issues are different from this bug(I'll open bug for my comment #37, if I can gather sufficient data.) As far as I know, at least followings do periodic access while you are sleeping. (1) Software update (2) RSS feed(Live bookmark) which is set "Check location for updates" (3) Bookmark which is set "Check location for updates" (4) "Site Icon"/"Favicon" update check (5) Periodic or timer pop activity by Extention. I disable all (1) to (4) and I have no additonal extention other than LiveHTTPHeadrs. Another concern is memory used for "Cache". Memory for cache related issue is not infinite increase usually, but it usually causes large memory usage. - Memory for "Fast back and forward"(bfcache) - Memory cache size default derived from large real memory size See Bug 320915 : [Meta] 1.8 memory leak campaign. To distinguish infinite increase of memory size while sleeping from simply large memory size, You'd better to do : (a) Disable bfcache (I already disabled because I have only 128MB) - Set browser.sessionhistory.max_total_viewers to 0(ZERO) - Set browser.sessionhistory.max_viewers to 0(ZERO) (b) Set memory cache size to relatively small (I set 8000) - Set browser.cache.memory.capacity to adequate size(Killo bytes) (c) If you install some extentions, you have to test at least without extention installed or new profile. To Eugene Savitsky: (Q1) After (a) to (c), can you check which of above (1) to (4) is cause, or above (1) to (4) can never be a cause. (Q2) Can you see some leaks of "Global Objects" by leak-gauge tool? See Bug 320915 Comment #28 for David Baron's leak-gauge tool.
Installed FF3.0 nightly (20060805) at work. Athlon 1700+ (1,46Ghz), 384Mb RAM. After 3 hours 180500 Kb in Mem and 466880 Kb in VM. Very much swaping...
(In reply to comment #40) > (snip) 384Mb RAM. > After 3 hours 180500 Kb in Mem and 466880 Kb in VM. Very much swaping... After bfcache feature(Firefox 1.5), as a result of deafult of bfcache=on, and as a result of some extention's severe memory leak problem(for example, AdBlock when Firefox 1.5.0 was released), many bugs about large memory size were opened, then meta Bug 320915 was opened, and Ben Goodger had to release following MozillaZine News article. http://www.mozillazine.org/talkback.html?article=8019 (Ben Goodger Explains Higher Memory Usage in Firefox 1.5) Eugene Savitsky, please test at least with bfcache=off and without extention, if your problem involves "simply huge memory size during usual use". Please read David Baron's blog pointed by Bug 320915 Comment #28. - http://dbaron.org/log/2006-01#d20060110 - http://dbaron.org/log/2006-01#d20060122
I have NO extention. Only Deepest Sender. What is disabled in FF3, sibce it is "not compatible". Bfcache is also no reason, since the branch builds (FF2.0, Tb2.0) run fine, only the trunk builds are affected and the time frame when it was started I have given.
(In reply to comment #42) > I have NO extention. > Bfcache is also no reason, since the branch builds (FF2.0, Tb2.0) run fine, > only the trunk builds are affected (snip) Oh I see. Sorry for my misunderstanding. Although I've found a condition of problem when SeaMonkey trunk Mail&News(comment #37. possibly similar to your Tb trunk problem of comment #8), I can't still find any condition of rapid memory increase when Browser. And, as I stated in comment #39, I disable almost all automatic server access option of Browser of SeaMonkey trunk, and I can't observe severe/rapid memory size increase when Browser only is started(on MS Win-2K). Do you enable (1) to (4) of my comment #39? Specific site or specific operation has relation to the problem? Anyway, can you test with leak-gauge tool? (See Bug 324145 and Bug 323402 for fruit of leak-gauge tool in analysis of memory leak problem.)
You do not understand. This leak happends when just browsing. No updates in Seamonkey are possible.
Installed the 2006091008 Seamonkey 1.5 on my notebook (Asus M5, Pentium M 1.8, 512 RAM. After about 12 hours of usage the mem stat is: In mem 329000 Virtual 810000 Thunderbird 3.0 20060913 after 3 hour of usage is In mem 175000 Virtual 177000
Flags: blocking1.9a1+
Keywords: mlk
Tested on my new Athlon X2 3800+, 2Gb RAM - the record of mem usage for Seamonkey 20061018 was 1,5Gb in RAM and 2Gb in Virtual. :)
Tested Thunderbird Version 3 alpha 1 (20061024) on my environment - Windows XP x64 SP1 on Dell Optiplex GX620 (P4-630/3GH), 1GB RAM After 19 hours of run, memory usage is 382MB in RAM and 1.57GB in Virtual. Also 19290 handles are remain opened. I'm using it with IMAP. It seems that the thunderbird missed to close handles of received mails.
Eugene, browser memory problems definitely are worse after threadmanager checkin viewing pages that use flash player. but there may be more than one problem here. 1. if you go back and recheck 20060509,nightly of thunderbird and seamonkey browser, can you confirm no problems on those builds? 2. after 20060509 do you ever see the thunderbird problem when seamonkey is NOT running? or seamonkey when thunderbird is not running? 3. two other questions - does your PC at work or home go in sleep, hibernate or standby? is your internet connection 100% reliable (doesn't go down)? I rarely see a big thunderbird memory problem but when I do it happens to all my mozilla products at the same time - bug 361247.
No longer depends on: 341430
Summary: Huge memory leak → Huge memory leak after 20060509 nightly (threadmanager checkin)
1. I had already stated that: ----- TB 20060508 (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-08-06-trunk/) uses 96Mb after almost 20 hours of usage. The next Tb 2006050908 (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-09-06-trunk/) uses much more memory. ----- 2. Never tried out, since I need my mail as well as browsing. But I'll try it out tomorrow. 3. Notebook does hibernates. The desktop never. Connection is reliable.
I tested overnight only Seamonkey (Thunderbird were not started), see the screenshot attached. 1.5Gb of RAM and almost 2Gb of VM were used by Seamonkey 07011508.
Attached image 070115 Seamonkey —
BTW The computer is: Athlon X2 3800+ (2Ghz), no o'c 2Gb RAM DDR2
Note: There are at least 2 classes of memory issues thought to be caused by or aggravated (made worse) by the threadmanager checkin: javascript, flash player/shockwave. Bear in mind both classes of issues have memory problem EVEN WITHOUT the threadmanager checkin. The question to be answered here is whether THIS problem, eugene's/reuben's, in Seamonkey browser is not one of the above classes. Detailed steps are absolutely necessary so that someone else can recreate the problem. Reuben, do you also see this in Seamonkey browser with no extensions, clean/new profile, and no sites that use flash player or shockwave images? If yes, please list some example URLs where you see the problem. (In reply to comment #50) > I tested overnight only Seamonkey (Thunderbird were not started), see the > screenshot attached. > > 1.5Gb of RAM and almost 2Gb of VM were used by Seamonkey 07011508. Eugene, what websites did you leave open overnight? (please cite URLs the future when reporting bad behavior) (In reply to comment #49) > 1. I had already stated that: > TB 20060508 > (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-08-06-trunk/) uses > 96Mb after almost 20 hours of usage. > > The next Tb 2006050908 > (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-09-06-trunk/) uses > much more memory. Eugene, your regression range regarding Thunderbird builds is http://tinyurl.com/3cjb6t which does NOT match up with the threadmanager checkin. TM checkin happened 2006-05-10 10:29 a full day after you say thunderbird uses more memory. This inconsistency is why in #1 I asked you to recheck you findings regarding Seamonkey. (Except for this aspect of your bug report, the Thunderbird issues should move to other TB bugs)
Summary: Huge memory leak after 20060509 nightly (threadmanager checkin) → Huge memory leak after 20060509 nightly (threadmanager checkin) in Seamonkey browser
This is not only Seamonkey. Thunderbird as well.
Summary: Huge memory leak after 20060509 nightly (threadmanager checkin) in Seamonkey browser → Huge memory leak after 20060509 nightly (threadmanager checkin)
About Thunderbird: comment 7. There are no TB builds to test when it started happening.
** from anyone - we still need a testcase/URLs, under these conditions - default theme - must be scenarios (pages) that do NOT have java or flash - disable google desktop sarch (GDS) if it's installed - bug 346361 things to try - (for mail users) delete inbox.msf - what if about:blank or only one web page is left open overnight? questions to answer - using proxy? - what URL(s)? Eugene in comment #54) > This is not only Seamonkey. Thunderbird as well. the purpose in putting seamonkey in the subject is a) so other seamonkey users can more readily search and find the bug b) so developers, triagers, etc don't have to read bug comments to get basic details c) so it is clear this bug is not about firefox having seamonkey in the summary doesn't mean this isn't a core bug, nor that thunderbird isn't related nor preclude people from discussing thunderbird. OTOH, it's not clear that it is helpful to discuss a seamonkey-non-mail problem and a thunderbird problem in the same bug. I had left thunderbird off the summary so as to not attract thunderbird users (a least not for now).
Summary: Huge memory leak after 20060509 nightly (threadmanager checkin) → Huge memory leak after 20060509 nightly (threadmanager checkin) in seamonkey browser and thunderbird
I still have been unable to narrow down exactly a cause of this bug (What triggers it) but it still happens pretty much daily. The latest build I am up to is Seamonkey 1.5a 2007011108. I only use Seamonkey for browsing. I am using the default theme, and the only extension I have installed is PrefBar (but I just put that in last weekend so I don't blame it. :) ) I do believe it has something to do with pages with Flash (Which I hope doesn't invalidate the bug), but I can't prove that at this moment. With that said, I've used Firefox 2/2.0.0.1 for a few days worth of browsing over the last few weeks, keeping an eye on its memory usage, and it never seems to go above 160mb-200mb. I just checked SeaMonkey on my home PC before I posted this and it was over 442mb and climbing, with one window open with 2-3 tabs. It had only been running for a couple of hours. (I never need to let it go overnight; at work, when I can have 2-3 windows with 10-15 tabs a piece, I regularly see 900mb of RAM usage after about 4-5 hours if I don't remember to restart Seamonkey) I have noticed newer builds seem more resilient to the skyrocketing memory use but again, I haven't been able to figure out the right combination of things to do to trigger it. (Which is frustrating as, like I said, I hit this every day at home and at work) I do use tabs and multiple windows together, so perhaps there is some sequence of what needs to be open to trigger it. In my experience it is not as much time left running as what pages I view that causes the problem. (i.e., sometimes it can take a ton of memory almost immediately, sometimes it takes a while) Sorry to not have more info but I will continue to try to figure out what triggers it on my systems.
A quick test case that looks promising: Start Seamonkey 'cold' (I have been killing the tray/quickstart icon before this) Go to http://www.laavengers.com (it does use Flash) Wait about 30-60 seconds After a little while, memory/VM use starts creeping up about 20-30kb per second. It doesn't start taking the memory immediately, but on my computer takes about a minute before it starts up. I have had Seamonkey idle on this page for about 20 minutes and I am up to 103mb memory and 95mb VM used, and it continues to creep up. The LA Avengers page is the only page open. Firefox 2.0.0.1 does seem to start using up more memory as well but it is MUCH slower. (I opened them both at roughly the same time and Firefox is only using 55MB memory and 45mb VM-- which are both only around 5mb over what it took when I started it up. Seamonkey started around 40MB in each category, as well) So, at least for this test, it does seem Flash related but Firefox does something differently to either work around this problem, or doesn't cause it to happen. I am using Flash 9.0.28.0 (latest available right now) and Seamonkey 1.5a 2007011108. I'll keep this test running for a bit and capture a screen of the task manager. (this is on Windows XP SP2) Let me know what else may be helpful.
There's a minimal Flash test case in bug 342810.
After about 2 minutes left alone, using the minimal Flash test case listed above and nothing else, Seamonkey begins to use up 4k/sec.
(sorry, should've been more specific-- 4k/sec in both Memory and VM)
I have run the minimal Flash test case in Firefox 2.0.0.1 for comparison and see very little movement in memory after 1 hour: (time, Mem Usage / VM Size) 11:37am: 33924 / 24140 12:08am: 34102 / 24092 12:37pm: 34028 / 24092 It doesn't appear the bug is there, at least in the same way, in Firefox, although I am comparing nightly builds of Seamonkey to a released Firefox. (not sure when the relevant components would be rolled into the main truck and as such be in both applications)
Justin, please reread comment 57 for what constitutes a useful testcase for this bug. flash examples are clearly NOT useful here. you can follow flash issues in bugs that have flash in the summary. but even there dont waste your time and others reporting examples, there are enough already, UNLESS your example clearly illustrates WHY and HOW flash by itself, or in it's interaction with gecko, is causing a problem - preferably with references to the relevant source code.
Summary: Huge memory leak after 20060509 nightly (threadmanager checkin) in seamonkey browser and thunderbird → Huge memory leak after 20060509 nightly (threadmanager checkin) in seamonkey browser and thunderbird - NOT f l a s h
Whiteboard: DO NOT REPORT FLASH PROBLEMS HERE
I run Seamonkey for about 12h with about:blank and the mem usage was not growing at all. So it is indeed some browsing problem, I could imagine Tb has the same problem rendering e-mails. i'll try to open Tb for night just recieving IMAP account. Will see how it behaves.
Hi Eugene. Re: thunderbird bug 364795 is a memory prob with 1.5.0.9, but perhaps it also exists on trunk. I suggest you test the ideas ongoing there and comment in 364795. Re: SM need the one or two URLs you leave open overnight.
Leaving TB 2007011909 for 8h just recieving mail = 390Mb RAM and 380Mb VM.
I can reliably get TB trunk (3.0) as of today to use about 1MB of memory (it varies, sometimes a few hundred K sometimes up to 2MB) and NOT visibly release it, at least according to Windows Task Manager, every time I manually "Get Mail". Given I have TB set to check for new mail automatically every 2 minutes this can add up to quite a lot of memory gobbled up over a few hours. I'm using IMAP (not IMAPs), with no extra plugins. TB 2.0 betas do not have this problem. I wonder if IMAP is the common factor in reports for this bug?
Reuben, did you mean 1Gb or 1Mb? I'm also using IMAP. 5 mailboxes.
1 MB *every* time I manually "Get Mail" - as I said...sometimes Task Manager shows a 500k increase, sometimes 1500k increase, but always goes up and never down. It adds up over a day to be many hundreds of MB of unfreed memory, which is reclaimed upon restarting TB. I can only reason that a manual "Get Mail" is having the same effect as an automatic check/poll every 2 minutes in so far as likely leaking memory as well. I only have one IMAP mailbox, however I have TB set to check for new mail in all folders (there would be maybe 30 or 40 folders).
Yep, indeed getting new mail increases the used mem. TB 2007012603 3.0a1.
Regarding Thunderbird ... (In reply to comment #16) > TB 20060508 > (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-08-06-trunk/) uses > 96Mb after almost 20 hours of usage. > > The next Tb 2006050908 > (http://archive.mozilla.org/pub/thunderbird/nightly/2006-05-09-06-trunk/) uses > much more memory. Eugene, can you retest to assure the difference in memory wasn't just caused by differing messages received in each test period? and determine whether thunderbird indeed regressed in that range (and thus not threadmanager)? To get a valid comparison you can start multiple thunderbirds at the same time, each to a different profile, by doing "set MOZ_NO_REMOTE=1" in a command window and starting thunderbird from that command window. http://kb.mozillazine.org/Run_multiple_copies_of_Thunderbird_at_the_same_time Reuben reports trunk thunderbird memory usage has gone down since 2007-01-17. Reuben can you determine when (with what build) it improved ? ... past builds at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/ Can you also see if the cause of your problem began in the range of builds listed in comment 56?
I do not use Sm for RSS. And now I'm on Vista on my desktop. I'll try it out on my notebook.
Blocks: 381699
Could someone check if bug 342810 ("2007-06-07 14:41") checkin solved this bug too ?
Eugene, there is no testcase afaict and I think you're the only left that sees this, so this puts you on the spot to check a nightly trunk build :)
Whiteboard: DO NOT REPORT FLASH PROBLEMS HERE → [need testcase] DO NOT REPORT FLASH PROBLEMS HERE
1) I'm using the latest Seamonkey build, but based on the old code (before changing to firefox tools or whatever) 2) I'm on Vista. 3) I'll compare FF 3.0a5 and latest trunk.
Any update on this, Eugene?
Dunno. After 3-4 uptime days Minefield 20070613 on Vista shows 278Mb in mem and 824 in swap. But on Vista the problem wasn't so big even befor the check-in.
Any information at this point suggesting this should not be closed WFM?
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Flags: blocking1.9?
No longer blocks: 381699
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: