285990 - Memory leak when switching between folders or POPping mail

Status: RESOLVED DUPLICATE of bug 266679

(Thunderbird :: Mail Window Front End, defect)

Description

[Mike Pennington]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

When I switch between folders, I see thunderbird.exe using more and more memory.
 It seems to grow without bounds.

Reproducible: Always

Steps to Reproduce:
1. Open task thunderbird and windows task manager
2. Switch between folders multiple times, or POP mail for an empty mailbox
3. Watch tbird's memory usage grow as you perform each step

Actual Results:  
More memory consumed

Expected Results:  
Thuderbird should not chew up infinite amounts of memory from switching between
folders or performing other common tasks.

I didn't use a special theme.

Comment 1

[Steve]

I'm seeing this as well.  After working with a few folders and even non-empty
POP accounts (but ones without any new email), thunderbird will grow to about
250MB.  

Comment 2

[David :Bienvenu]

we're not closing DB's. I'll figure out why. It could be the ref-counting
problem dbaron pointed out a week ago...

Comment 3

[Steve]

(In reply to comment #2)
> we're not closing DB's. I'll figure out why. It could be the ref-counting
> problem dbaron pointed out a week ago...

Bug 285684 questioned whether Google Desktop was somehow involved.  As I wrote
there, this memory leak problem did start around the same time I installed it
(the most recent version only) and stopped when I uninstalled.

Perhaps Google Desktop is falling victim to the ref-counting bug and thus
databases that it opens to search aren't being properly released?  

Comment 4

[Mike Pennington]

I can reproduce the problem at will on computers that do not have Google Desktop
installed; however, Google Desktop seems to increase the impact of the issue

Comment 5

[Mike Pennington]

Attachment: How to measure & reproduce the problem

A list of screen shots and text to describe reproduction of the memory leak.

Comment 6

[David :Bienvenu]

Google Desktop search is a separate issue

*** This bug has been marked as a duplicate of 287847 ***

Comment 7

[Mike Pennington]

I just loaded the Latest-Trunk 20050416 build and reproduced using the same
procedure attached above.  Is there a different nightly I should use?

Ref:
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ThunderbirdSetup.exe

Comment 8

[http://tinymailto.com/oliversl]

related to bug #206502 ?

Comment 9

[vincent]

Hello, 

I have the same problem on a PC (Win98SE/Thunderbird 1.0.2) with 2 POP accounts
(no IMAP). The first account is nearly empty, the second has an inbox file of
roughly 500Mo.

The PC was slow and after a quick check I noticed that there was no memory left.
I added 256Mb to the existing 256Mb. Unfortunately after 5 minutes, thunderbird
stole the additionnal 256Mo.
--> The RAM is not stolen if thunderbird does not run.
When I click on the inbox of the second pop account, I can see the previous
(cached?!) state of the message list and the wheel at the upper right corner is
animated. After a 10-20 minutes, I can see the refreshed message list.

Weird.
Next step I will try is to move all POPed emails to an IMAP account. Clean
everything and retransfer all mails back to the POP Inbox account. Perhaps is
the current POP account is somehow corrupted ?!

Keep in touch.

Comment 10

[David :Bienvenu]

Did you recreate the problem on a recent trunk build w/o Google Desktop Search
installed?

This isn't (and won't) be fixed in 1.02 - it's only fixed in trunk builds.

Comment 11

[vincent]

For info, 'Google Desktop Search' is not installed. I can try to install the
latest build if you think that the problem has been solved.

Comment 12

[David :Bienvenu]

Vincent, if you were using 1.0x, then yes, I'd suggest trying a recent trunk build.

Comment 13

[David :Bienvenu]

again, please don't try this in a 1.0x build and report that it's not fixed. It should be fixed in 1.5beta2 and trunk builds.

*** This bug has been marked as a duplicate of 266679 ***