performance issue freezes thunderbird during startup and delays password entry with status bar "determining which messages to index"

RESOLVED WORKSFORME

Status

Thunderbird
Search
--
major
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: wsmwk, Unassigned)

Tracking

({perf})

x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [has stacktrace])

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
In working with RC1, on several occasions I am unable to enter master password for several seconds, anywhere from 10-50 seconds. During this period status bar shows "determining which messages to index" and ms-windows' task manager indicates thunderbird is "not responding".  CPU is low

This is on an existing profile on XP. The profile has several imap, RSS and news accounts.

I have another bug I'll be filing, which may be related.
(Reporter)

Comment 1

8 years ago
andrew, what's likelihood this was resolved by subsequent patches, i.e. post RC1?

I haven't seen this in a while. but i've also stopped using master password and moved my mail off that machine. I'd welcome someone else testing if asuth has no reason to believe the problem is gone

1. >1 imap account
2. set master password, do not save account passwords
3. open a few tabs with different accounts
4. shutdown
5. start
6. see master password prompt (if not, click on an account)

see "determining which messages to index". UI is locked
Severity: major → normal
Whiteboard: closeme 2010-02-15
I think there was a multiple master password prompt fix that went in.  I don't know enough about that, but could easily see that doing bad things to the event loop or apparently bad things.

That's a more likely explanation for the real problem and why it might have gone away.  The activity manager hookup to the status bar is misleading... all it really tells us is that the activity it is talking about got started sometime in the past.  It is no indicator that the activity is ongoing.

...gloda should not be triggering things involving credentials; it relies on others to keep folders in sync with the server.  Gloda could certainly help create a more complex problem for other bugs though.

Comment 3

8 years ago
I'm seeing exactly this issue with master password off, gloda index on, and lightning installed, in Lanikai.  I didn't see it until I turned on gloda indexing yesterday.

I think you've got a multi-threading issue between the auth system and the indexer somehow.  As you know, there is  currently a bug in lightning that causes a password prompt to show up the first time you start thunderbird.  When that happens on startup, I can usually click through it (as it remembers my password) but then after a few seconds, Thunderbird goes into the "Determining which messages to index" state and hangs.  It doesn't chew much CPU, at all, but it constantly beachballs in the background.

I'll attach a sample from the process.

Bug 542498 seems to also be somewhat related to this issue.

I'm running Lanikai nightlies: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.2pre) Gecko/20100209 Lightning/1.0pre Lanikai/3.1b1pre

Comment 4

8 years ago
Created attachment 426687 [details]
The sample from Mac OS
(Reporter)

Updated

8 years ago
Severity: normal → major
Whiteboard: closeme 2010-02-15 → [has stacktrace]
(Reporter)

Comment 5

8 years ago
Created attachment 430357 [details]
windbg hang stacktrace from 02-22, on vista during startup, 3.1b 20100221

I mailed this stack to asuth and bienvenu earlier today. bienvenu wrote "looks like sqlite is blocked on file i/o"
3.1 nightly builds are not made against our patched mozilla-1.9.2 release branch.  This happens as a result.

Bug 545625 in conjunction with bug 545621 are the solution.  Those should happen over the course of the next few days.
(In reply to comment #6)
> 3.1 nightly builds are not made against our patched mozilla-1.9.2 release
> branch.  This happens as a result.

Not quite true at the moment. As of Tuesday we switched the 3.1 nightlies back onto our relbranch.

> Bug 545625 in conjunction with bug 545621 are the solution.  Those should
> happen over the course of the next few days.

Assuming these land in a reasonable time frame I'd expect 3.1 to be sticking with a "fixed" version from now on.
WFMing since true-async is good to go on all comm-1.9.2 builds and I fixed the absurd deletion problem that was likely the trigger.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.