525646 - Mass delete of messages resulted in massive memory usage

Status: RESOLVED FIXED

(Thunderbird :: Folder and Message Lists, defect)

Description

[Allan Beaufour]

1. clicked on an IMAP folder
2. searched by subject
3. selected all messages that matched (16000+)
4. clicked the delete button
Result: tb3.0b4 started eating memory like there was no tomorrow. Around 100MB/sec or so of virtual memory, so I killed it.

I submitted an Apple bug report (or whatever the correct name is :) ), but I cannot remember if/how I can link that in here.

Comment 1

[David :Bienvenu]

probably a dup of bug 519226

Comment 2

[Allan Beaufour]

Easily reproducible btw, I just tried again and hit 3GB of virtual mem in an instant, before I nuked the process.

Comment 3

[David :Bienvenu]

OK, I've figured this out. I have a simple fix for tb 3.0, but a better fix will have to wait for 3.1.

Comment 4

[David :Bienvenu]

Attachment: proposed fix

We were creating messageIds strings for all 4000 messages for each undo object, but with a single message key. Needless to say, memory usage got crazy. We really should be trying to create a single undo object for the batch delete, but it's a bit scary (actually, several undo objects because there are several sub-operations in the undo queue for a single delete).

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 410691 [details] [diff] [review]
proposed fix

>-  rv = GetChildWithURI(uri, PR_FALSE/*deep*/, PR_FALSE /*case Insensitive*/, getter_AddRefs(msgFolder));
>+  PRBool caseInsensitive = mIsServer && name.EqualsLiteral("INBOX");
>+  rv = GetChildWithURI(uri, PR_FALSE/*deep*/, caseInsensitive /*case Insensitive*/, getter_AddRefs(msgFolder));

This looks like part of a different patch and shouldn't be here?
 
>+      nsCString messageId;

I think messageIds is now obsolete - so that should be removed.

r+sr=Standard8 with those fixed.

Comment 6

[David :Bienvenu]

fixed on trunk and branch with review comments addressed.