477780 - TB3B1 Freeze ~5-10 seconds after startup when gloda kicks in

Status: RESOLVED DUPLICATE of bug 470329

(MailNews Core :: Database, defect)

Description

[zeroflag]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 (.NET CLR 2.0.50727; .NET CLR 3.0.30618; .NET CLR 3.5.21022; .NET CLR 3.5.30729)
Build Identifier: Thunderbird 3 Beta 1

No matter what I do (I can enter the options, check addons, even browse through my mail) TB freezes after some sort of initialization (the progress bar at the bottom loops a couple of times) TB enters a loop (100% CPU on a single thread) and, after a couple of seconds, consumes ridiculous amounts of RAM - up to 600MB before it "resets" and starts growing again and eventually causes other applications to fail (e.g. FF3 stopping scripts).

Using TB2 I managed to disable automatic mail-updates but I don't think that works for my IMAP box.

My TB3B1 Setup:
- 1 IMAP box
- 1 POP3 box (automatic checking/downloading disabled)
- all addons (including nightly tester tools) disabled
- Junk filters enabled
- Vista Search Indexer enabled (which it asked me to during installation, but now I can't find a way to turn it off)

My System Setup:
- Vista SP1
- All sorts of updates installed (I'm software developer using tons of microsoft tools so I have to keep everything updated)
- Intel Core 2 Duo
- 2GB RAM
- Slow-as-hell notebook HDD
- User/"home" directories on fileserver over (slow-as-hell notebook) LAN

Reproducible: Always

Steps to Reproduce:
1. Start TB3B1
2. Do anything for up to 10 seconds.
3. Kill the process before it kills the RAM.

Comment 1

[zeroflag]

Update:
I managed to go offline without synchronizing to my IMAP folder => Doesn't freeze anymore.

Comment 2

[Rain [:rain1] (inactive)]

This might be an interaction between a networked drive and Vista indexing. To disable Vista search indexing, set the mail.winsearch.enable preference to false. (You can do this from within Thunderbird 2, using Tools -> Options -> Advanced -> Config Editor.)

Can you see if the problem gets fixed after you've disabled it?

Comment 3

[zeroflag]

I managed to disable the Message Indexer in TB3B1 completely and that seems to be a temporary workaround for the freeze.

Comment 4

[Rain [:rain1] (inactive)]

By the message indexer, are you referring to the option in Tools -> Options -> Advanced, or Vista search indexing?

Comment 5

[zeroflag]

(In reply to comment #4)
> By the message indexer, are you referring to the option in Tools -> Options ->
> Advanced, or Vista search indexing?

The option in TB3.

I also disabled the windows indexing and tried to re-enable the Message Indexer in TB3 but it started freezing again.

Comment 6

[Rain [:rain1] (inactive)]

CCing asuth, can you have a look at this? Sounds like gloda or the backend storage engine isn't behaving too well.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Yeah, this sounds like gloda.  Gloda starts performing its startup indexing sweep after 10 seconds, and without the patch on bug 470329, things can get ugly.  Prior to the patch, the commit decision constant was arguably on the low side, and worse than that, the logic involved was inconsistent with the other scheduling logic.  The memory usage is likely caused by XPConnect's deferred release mechanism; prior to the patch, our rate of forced garbage collection cycles was probably too low to be making much of a difference in terms of memory usage.