485368 - excessive memory usage, CPU loop, possible failure, on bulk message move or delete

Status: RESOLVED WORKSFORME

(Thunderbird :: Folder and Message Lists, defect)

Description

[Dan Evans]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
Build Identifier: version 2.0.0.21 (20090302)

in a POP3 account, after messages have been downloaded from a server, deleting or moving a large number of messages, 50 to 100 at once, causes the following:
1) messages are copied to Trash or target folder
2) after this, TBird goes into a CPU loop and begins allocating 8-12 megs of memory per second, as seen in Windows Task Manager - have seen Virtual Memory go above 1G
3) if number of messages is toward lower end (50) and machine has enough memory, CPU loop ultimately terminates and memory is deallocated over a period of 5-10 seconds, screen is refreshed
4) if machine does not have enough memory and/or number of messages is too large, various problems occur due to memory/CPU starvation
5) if TBird terminated using Task Manager before failure, after restart, messages are in target folder but have not been removed from source folder

Reproducible: Always




This may be the same problem as reported in other bugs such as 371146, 406204, 263327, but I believe this report provides additional info not reported in those bugs.

Comment 1

[WADA:World Anti-bad-Duping Agency]

> 2) after this, TBird goes into a CPU loop
> and begins allocating 8-12 megs of memory per second,
> as seen in Windows Task Manager - have seen Virtual Memory go above 1G
> 3) if number of messages is toward lower end (50) and machine has enough memory,
> CPU loop ultimately terminates and memory is deallocated over a period of 5-10 seconds, screen is refreshed

"CPU loop upon delete" sounds to be same phenomenon as Bug 452221.
"Big virtual memory" sounds to be phenomenon reported to Bug 296453.
Long or deep mail thread? Do you use "View/Thread" when you deleted mails?

Comment 2

[Dan Evans]

View/Thread was not used.  Mail was displayed in order received.  My experience definitely seems similar to Bug 452221, but I am not using anything unusual with regard to View.  It is also similar to Bug 296453, but the account uses a POP3 server, not IMAP.   I have traced (Ethereal) the TBird/server interactions and during this incident, there is no interaction, so I think the problem is not related to the server type.

Comment 3

[Eric Liao]

I got the same problem. It seems cause by "Google Desktop" that mentioned in BUG 315691.
When I disabled "Google Desktop", this problem didn't happen.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> It is also similar to Bug 296453, but the account uses a POP3 server, not IMAP.
> so I think the problem is not related to the server type.

You are right. I've removed "IMAP" from bug summary of Bug 296453 to avoid confusion, misleading. 

Dan Evans(bug opener), do you use "Google Desktop"?

Comment 5

[Dan Evans]

I do use Google Desktop, but I can't remember if it was running at the time I observed the bug.  GD has its own memory leaks and grows slowly over time, so I don't run it continually.  I will try to reproduce the bug without GD running, but it requires queueing up a lot of Emails so it may be a while. -- However, it's not clear to me how the simple existence of another address space could affect TBird.  Are there some (Win) messages that GD sends to any mail agent that it finds running, or are there some messages that TBird will accept from external processes that condition its behavior in some way?

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #5)
> However, it's not clear to me how the simple existence of another address space could affect TBird.

Google Desktop is never "simple existence of another address space" for Tb.
> http://en.wikipedia.org/wiki/Google_Desktop
> Features
>(snip)
> File indexing
>(snip)
> Google Desktop can index several different types of data, including email,(snip)
>(snip)
> Email indexing
> Google Desktop includes plugins that allow one to index and search through the contents of 
> local Microsoft Outlook, IBM Lotus Notes, and Mozilla Thunderbird email databases, 
> outside of the client applications' built-in search functions.
>(snip)

Comment 7

[Dan Evans]

Sorry for not following up sooner.  I tried to recreate this by restarting TBird, then loading up 600 unread emails into an account's Inbox, then moving in 3 chunks 100, 200, and 300 mails to another folder under the same account.  I was not able to reproduce the issue I initially saw which prompted this report, whether GD was running or not.  I have to note that since I originally submitted this report, I have upgraded Thunderbird, which is now at 2.0.0.23 (20090812).  I guess this can be closed.