Thunderbird + Lightning 0.8 uses 100% CPU

[Kolargol00]

Binary package hint: thunderbird

After upgrading from Lightning 0.7 to 0.8 launching Mozilla Thunderbird (2.0.0.12) uses 100% CPU apparently forever and for no reason. The application seems usable though (not frozen).

ProblemType: Bug
Architecture: i386
Date: Thu Apr 10 17:38:58 2008
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/lib/thunderbird/thunderbird-bin
NonfreeKernelModules: nvidia
Package: thunderbird 2.0.0.12+nobinonly-0ubuntu0.7.10.0
PackageArchitecture: i386
ProcCmdline: /usr/lib/thunderbird/thunderbird-bin
ProcCwd: /home/edysli
ProcEnviron:
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: thunderbird
Uname: Linux Macharia 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

[Chabrie (chabrie)]

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2; FDM)
Build Identifier: TB Version 2.0.0.5 (20070716) - Lightning 0.5

Configuration:

4 imap based mail accounts with SSL connection to the mailserver and two webdav based ics calendar files (around 500KB) with https connection to CMS server (Internet with dsl 16M/1M connection).

Problem:

Reproducable timing bug in Lightning leads to endless CPU usage of 50% (Dual Core), if a calendar action (PUT/GET) is started at the same time like mail transfer. No more calendar actions useable until killing TB process.

Reproducible: Always

Steps to Reproduce:
1. Insert an event to the webdav calendar with an invitation via email
2. If the mail window is closed to early (to send the invitation), the thunderbird process gets 50% cpu until killing the process. No calendar actions are useable until reopening thunderbird after killing process.
3. Deactivating all security features of mail transfer (no SSL IMAP/SMTP), the problem does not occur.
Actual Results:
Same results with TB portable and Lightning 0.5. add-on. Sunbird does not have the problem, because of separate threads and missing email invitation functionality. Sometimes the webdav based calendar file is corrupt after this bug.

[Ssitter (ssitter)]

Do you see any error messages in the Error Console?

[Chabrie (chabrie)]

I see the following logs in the error console:

gCacheStyleSheet is not defined
chrome://lightning/content/calUtils.js
in Zeile 111

and

standard has no properties
chrome://calendar/content/calUtils.js
in Zeile 167

If anybody needs an imap account and a webdav account for testing, I see no problem. We could reproduce the error oon several systems.

[Ssitter (ssitter)]

Frank, does the issue still exists using Lightning 0.7 Release Candidate 1?
<http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.7rc1/>

The last error could be related to Bug 396580 or Bug 396873.

[Christoph E (mail-christoph-evers)]

Today I got the latest Lightning 0.8 RC2 (have been using 0.7 before) and have a very similar problem as Frank has:

Using an IMAP SSL Account together with an https caldav calendar makes Thunderbird stuck with 50% (dual core) CPU load. If I disable SSL in the IMAP account everything works fine. Unlike Frank, I can close my Thunderbird regulary. It just does not retrieve any email and calendar information. The error console does not report anything. Also, the problem will first come up when you restart Thunderbird (if you changed the settings). For instance, if you add a new https calendar into lightning then this new calendar will work until you restart Thunderbird.

This problem does not occur in Lightning 0.7 only with newer 0.8 RC2.

[Temp2000 (temp2000)]

I see a similar problem on a friend's computer, but in this case she's using an https connection to the webdav server and a secure SSL connection to the POP3 server (not IMAP). As Frank said, it seems to happen when she changes the calendar during a timed mail check. The timed mail checks happen every five minutes so she sees this problem at least once per day. In this case it doesn't matter if it's a meeting invite (she doesn't send or receive them).

The CPU was at 100% and I had to kill Thunderbird. Before I killed it I checked the current internet connections using Process Explorer. Thunderbird had open connections to both the POP3 server and the webdav server. The connections were stuck in the "Close_Waiting" state. Both servers are at FastMail.

This is on a single core 1.0 GHz CPU (WinXP), a high-speed internet connection, and the ICS file is over 100 KB. I forgot to check the Error Console but it's too late now because she wasn't happy so I switched her calendar to a local ICS file. She's using the 0.7 release version of Lightning and Thunderbird 2.0.0.9.

[Kolargol00 (kolargol00)]

Reading email doesn't work anymore in this case.

I've found out that preventing TB from checking email accounts at launch prevented this problem. I can log in and read emails after that.

[John Vivirito (gnomefreak)]

This is not Thunderbird its lightning doing this and we dont support .8 yet not until Hardy+1. I will work on getting 0.8 in Hardy as a badckport once ive built it and tested it for Hardy+1 . I will start on this in may-june.

[Kolargol00 (kolargol00)]

All right, I'll bug Mozilla with it then... ;)

[Kolargol00 (kolargol00)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=428522

[John Vivirito (gnomefreak)]

Kolargol, Thank you i will look into the upstream bug when i start on 0.8 for Hardy+1.

[Bernard-desruisseaux (bernard-desruisseaux)]

Multiple users have reported this issue at Oracle. See:

https://bugzilla.mozilla.org/show_bug.cgi?id=422618#c25

Using Process Explorer we were able to identify the thread that was taking all
the CPU (50% on a Core2 Duo) in thunderbird.exe and look at the thread stack.
From what we've seen the thread was looping in
nsPrintSettings::GetStartPageRange. I don't know if that makes any sense or
not.

[Ssitter (ssitter)]

*** Bug 422618 has been marked as a duplicate of this bug. ***

[Ssitter (ssitter)]

*** Bug 428522 has been marked as a duplicate of this bug. ***

[Ssitter (ssitter)]

Confirming per duplicates.

[Dmose (dmose)]

This seems like a pretty serious failure mode; requesting blocking.

[Philipp-bugzilla (philipp-bugzilla)]

I tried to reproduce this, but from reading the previous comments it seems this issue only happens under special circmstances so its quite obvious that I couldn't. I tried the following:

* gmail imap server
* my webdav https server

- accept an event from the gmail server into the webdav calendar
--> Fails, but without error. Might be something else, no hang

- read mail, add/modify events
--> No error, no hang

Is this maybe OS dependant? Are there any sure-fire steps to reproduce this?

[Christoph E (mail-christoph-evers)]

Maybe it depends also from the IMAP Sever itself. For me it happens as soon as I have SSL enabled for both, calendar and imap. It does not matter in which order I enable SSL (first imap or first calendar). It hangs immediatley after restarting TB while connecting to the imap/calendar server. Can be reproduced on Win XP 32Bit and Ubuntu 64bit

[Philipp-bugzilla (philipp-bugzilla)]

What type of IMAP server do you use? What sort of webdav server do you use? Is the IMAP server on the same host as the SSL webdav server? What

I used gmail as imap and apache mod_dav for webdav/

[Mdelorme-tennaxia (mdelorme-tennaxia)]

(In reply to comment #13)
In my case
> What type of IMAP server do you use?
Cyrus
What sort of webdav server do you use?
DaviCal
> Is
> the IMAP server on the same host as the SSL webdav server?
Yes

[Christoph E (mail-christoph-evers)]

(In reply to comment #13)
> What type of IMAP server do you use?
Don't know. Host ist for example imap.strato.de

>What sort of webdav server do you use?
DaviCal Caldav server

>Is the IMAP server on the same host as the SSL webdav server?
No

[Dmose (dmose)]

See bug 422618 comment 25 for steps on how to reproduce.

[Kai Engert (kaie)]

the 50% busy sounds like a dual core computer with one cpu busy at 100% ?

although highly unlikely, just to be sure, can you trace the IMAP code and check whether it is doing additional i/o in the ssl test case?

can you use a packet sniffer and check whether there is constantly data being transfered, or whether the connection is idle?

if there is constantly data being transfered, one might use a tool like ssltap to snoop the ssl traffic to see what's going on.

is this specific to windows or happening on all platforms?

I know the SSL thread is doing a busy wait on SSL I/O under certain circumstances, if NSPR is unable to create a loopback socket for implementing the nspr pollable event

[Jaap van Ginkel (j-a-vanginkel)]

(In reply to comment #13)
> What type of IMAP server do you use?
Exchange server imaps

>What sort of webdav server do you use?
DaviCal Caldav server

>Is the IMAP server on the same host as the SSL webdav server?
No

[bvdbos (bvdbos)]

(In reply to comment #17)
> the 50% busy sounds like a dual core computer with one cpu busy at 100% ?

Judging similar reports in bugzilla it seems like this.

> I know the SSL thread is doing a busy wait on SSL I/O under certain
> circumstances, if NSPR is unable to create a loopback socket for implementing
> the nspr pollable event

Shouldn't the busy wait be something like 15 seconds max as a server-setting? I see comment 18, comment 14 and comment 15 (the three confirmed setups) all use Davical. Judging http://wiki.davical.org/w/Road_Map ssl-encryption doesn't work for Davical?

[Mdelorme-tennaxia (mdelorme-tennaxia)]

(In reply to comment #19)

> Judging http://wiki.davical.org/w/Road_Map ssl-encryption doesn't work
> for Davical?

Davical use the mod-SSL of Apache to support ssl-encryption (Davical is in PHP and use Apache)
(In reply to comment #17)
> the 50% busy sounds like a dual core computer with one cpu busy at 100% ?
I confirm that in my computer the 50% are for one core at 100%

[bvdbos (bvdbos)]

> Davical use the mod-SSL of Apache to support ssl-encryption (Davical is in PHP
> and use Apache)

I thought it had to be something like this :-) I see Maxime uses DaviCal 0.9.1, I wonder wether the version of the DaviCal server makes a difference. Bernard, which server does Oracle use? Jaap and Christoph, which versions do you use? As bug 416239 should be solved for caldav since 25-07, do you still see this with a recent nightly?

[Bugzilla-axel-naumann (bugzilla-axel-naumann)]

I use Lightning build 2008073119, Apple's CalendarServer SVN from 2008-01-11 on a Debian box, and Courier as IMAP, with both IMAPS and CalDav's https - and I see the same problem, in about 80% of all starts of thunderbird. AFAICS CalendarServer does not use Apache internally.

[Bernard-desruisseaux (bernard-desruisseaux)]

(In reply to comment #21)
> Bernard, which server does Oracle use?

We're using both the CalDAV and IMAP servers part of Oracle Beehive.

[Jaap van Ginkel (j-a-vanginkel)]

>Jaap and Christoph, which versions do you use?
>As bug 416239 should be solved for caldav since 25-07, do you still see this
>with a recent nightly?

ii rscds 0.9.5.1 DAViCal CalDAV Server

No errors on error console

100% CPU on single core box 50% on dual core

Very unresposive but not totaly dead 99% CPU sometimes

[Jaap van Ginkel (j-a-vanginkel)]

Oh sorry Lightning version Nightly build 0.9.pre 2008073119

[Bruno Browning (browning)]

For CalDAV users, with recent nightlies there are two preferences that you could set, calendar.debug.log and calendar.debug.log.verbose, that will significantly increase the amount of data being logged; that might help getting to the bottom of this. Also, as Kai suggested in comment #17, it would be useful if someone could wireshark a machine with this problem to see if there is network traffic associated with the CPU load. His question as to platform is also a good one - does this happen on Windows only?

[Bugzilla-axel-naumann (bugzilla-axel-naumann)]

I created the two preference settings as integers in the option's config editor, with their value set to 10000 (the more the better? :-) Where should I see the output? There is not a single line in the error console, even though it's set to display "All".

I noticed that the same issue shows up without network connection, i.e. with all network interfaces turned off. Windows (and yes, I have only tested on windows so far) does not show any network traffic on its interface.

Would you know of of a thunderbird binary with debug symbols? It should allow me to attach a debugger and tell you what keeps my CPU busy. Without I can basically only tell you what dlls the 17 threads are in.

[Bruno Browning (browning)]

Sorry not to have been more explicit: those prefs want to be booleans set to 'true'. The .verbose one is not in 0.8; you'll want to use a fairly new nightly to take advantage of it.
FWIW I've not been able to reproduce this on Linux - and I've tried.
I don't know where one could find a debug binary short of building one.

[Jaap van Ginkel (j-a-vanginkel)]

Updated to the agust 4th Nightly

I've been running with .verbose for a few hours now.

For some reason I can't reproduce the error anymore though Thunderbird is eating CPU cycles every time I touch anything calendar like, It gets sluggish but no more 100% usage.

Nothing out off the ordinari in the logging. Even eating 40% cpu with no extra loging.

[Bugzilla-axel-naumann (bugzilla-axel-naumann)]

OK, got it (well, the debug output :-) working, thanks. The last two messages I see are

CalDAV: recv: <?xml version='1.0' encoding='UTF-8'?>
<multistatus xmlns='DAV:'>
  <response>
    <href>/calendars/users/axel/calendar/2e0b9500-0087-4e08-bb63-b880483c0fb9.ics</href>
    <propstat>
      <prop>
        <getetag>"ddbb339c33e6de012516a516690431c5"</getetag>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
[...]
  <response>
    <href>/calendars/users/axel/calendar/a4902178-1465-41ab-9ae1-ec37327367d6.ics</href>
    <propstat>
      <prop>
        <getetag>"f38036e9996d56df10039b49783c75e1"</getetag>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
  <response>
    <href>/calendars/users/axel/calendar/ba61862e-6ec9-4165-94ca-2fffe5a0a11f.ics</href>
    <propstat>
      <prop>
        <getetag>"eeee26c5605e6211d4f740e0f48edd79"</getetag>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>
CalDAV: send: <?xml version="1.0" encoding="UTF-8"?>
<calendar-multiget xmlns:D="DAV:" xmlns="urn:ietf:params:xml:ns:caldav">
  <D:prop>
    <D:getetag/>
    <calendar-data/>
  </D:prop>
  <href xmlns="DAV:">/calendars/users/axel/calendar/ba61862e-6ec9-4165-94ca-2fffe5a0a11f.ics</href>
[...]
  <href xmlns="DAV:">/calendars/users/axel/calendar/eb72ddf8-a764-42f9-aaab-ebecafe2f19c.ics</href>
  <href xmlns="DAV:">/calendars/users/axel/calendar/b650acf2-4e2d-4a9a-8c5f-732f0e15d1ba.ics</href>
  <href xmlns="DAV:">/calendars/users/axel/calendar/f65900c6-4e1a-4b92-9129-6e196a660775.ics</href>
</calendar-multiget>

After that it hangs with 100% CPU (on one core). So that probably doesn't help.

I now have a x86_64 debug build for linux - which doesn't show the problem :-( So to me it looks like it's windows only. I'll post my findings once I have the debug build for windows.

[Kai Engert (kaie)]

Axel, if it's really Windows only, that might support my theory.
Do you have some Security Firewall enabled on your Windows system, that does prevent Firefox from opening a server socket on the loopback device?

[Bugzilla-axel-naumann (bugzilla-axel-naumann)]

No firewall but the Windows one. Disabling it has no effect; thunderbird still hangs. Process Explorer tells me that thunderbird has opened four local sockets (say port 2283-2286). 2283 connects to 2284, 2285 to 2286. All connections are in the "established" state. That's the case both when thunderbird and lightning work and when they hang.

[Kai Engert (kaie)]

I had not realized (until now) that we're talking about a real hang, I had assumed we just waste the cpu cycles.

So we've got a real deadlock, and that's not likely to be related to the busy wait I have mentioned.

Ideally someone who is would attach a debugger and get stack traces of all threads.

[Dennis Melentyev (dennis-melentyev)]

Thanks Stefan!

Silly me.
Just installed nightly build.
Works so far.

[Kai Engert (kaie)]

Are you saying the problem is gone?

[Kai Engert (kaie)]

Created attachment 361985
Patch v1

This is my first attempt to get the multiple worker threads implemented.

It seems to work for me, but unfortunately I see a crash when having the flash plugin installed, so I suspect this patch needs some more reviewing to find the bug.

But before we try to get this in, we must have reliable steps to reproduce the original deadlock/hang problem with Thunderbird 3 nightlies.

[Dennis Melentyev (dennis-melentyev)]

(In reply to comment #86)
> Are you saying the problem is gone?
Not yet - have to setup IMAP folder first.
Those problems described in bug 444537 and bug 458690 are not visible anymore
for me, but definitely were connected to SSL issues.

[Kai Engert (kaie)]

I would appreciate testing and feedback from someone who is able to reproduce this bug with TB 2.

I have been running Thunderbird 3 test versions, I have 3 IMAP/SSL accounts configured, I have 3 remote https calendar configured.

I configured all mail accounts to check for new mail every 1 minute, and to reload all remote calendars every one minute.

What I can see are slowdowns when using Thunderbird. It appears to stall for 1-2 seconds occassionally, probably as calendar data is being processed.

But I don't get any deadlocks, have been running this configuration for over 2 days. Linux.

[Dmose (dmose)]

Simon, is this something you can reproduce on trunk or 1.9.1?

[Nomisvai (nomisvai)]

One IMAPS account and 2 CalDAV accounts with HTTPS URLs. All connecting to the same host through a slow VPN connection (It's harder to reproduce is the network is fast). CPU is Quad core so I get 25% cpu usage when the bug happens.

With TB2:
1) Send a 500k mail to yourself, quit TB main window while it's sending (so TB quits right after the mail is sent)
2) Start TB again, click on the new mail header, quickly go to calendar pane and do a "reload calendars", go back to mail headers and click on the new mail again.

With my setup I can reproduce it about 50% of the time in the first 5 seconds of starting it up (After that it usually never locks up).

The same test with TB3 does not seem to cause any issue.

[Dmose (dmose)]

Since noone has yet been able to reproduce this bug on the trunk, removing [tbneeds]. If someone does manage to reproduce it, please re-add that keyword!

I wonder if the nsIThreadManager changes that happened after 1.8 are working in our favor.

[Larry (larryoleary)]

I appear to be having this same issue in TB version 2.0.0.19 (20090105) and Lightning 0.9.

I am using one IMAPS server and one CalDAVS calendar. On start-up TB goes to 100% CPU and has no network capabilities. If I remove the CalDAVS calendar and restart TB seems to work again.

So, from my perspective, it appears that Lightning doesn't work with CalDAV as it renders TB useless. I do not have non SSL calendar sources available so I wouldn't know that Lightning worked with non-SSL CalDAV.

[Mteixeira (mteixeira)]

I noticed the SSL issue while reading calendars from a Zimbra server.

Is there anyway I can try the latest trunk using Thunderbird 2.0?

[Kai Engert (kaie)]

(In reply to comment #94)
> I noticed the SSL issue while reading calendars from a Zimbra server.
>
> Is there anyway I can try the latest trunk using Thunderbird 2.0?

Which latest trunk do you refer to?
As you say "latest trunk" with TB2, I guess you are referring to "Lightning trunk".
This combination won't help you, as the bug is in the core TB code.

[Kai Engert (kaie)]

(In reply to comment #92)
> Since noone has yet been able to reproduce this bug on the trunk, removing
> [tbneeds]. If someone does manage to reproduce it, please re-add that keyword!
>
> I wonder if the nsIThreadManager changes that happened after 1.8 are working in
> our favor.

I found one more difference. We never added the enhancement from bug 363455 to 1.8 branch, so TB 2 does not have it. That patch is meant to improve handling of blocking sockets. It would be interesting to know if it helps for this bug. I backported the patch, you find it in bug 363455 attachment 365683.
Would someone of you who is still using TB 2 be able to try that patch?

[Dmose (dmose)]

Versions have moved since some of the past comments were written.

The case that's really most critical at this point is ensuring that the nightly versions built from the mozilla-central trunk of Lightning <http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/> (next Lightning will ship from 1.9.1, but we don't have builds for that yet) and Thunderbird <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/> (Thunderbird 3.0 will ship from here) work well together and don't have this problem.

Note that as of this writing, comm-central hasn't yet branched, though it will in the not-too-distant future.

[Dmose (dmose)]

I've filed bug 481685 to track getting mozilla-1.9.1-based builds of Lightning.

[Dmose (dmose)]

It appears that I was confused, and we do already have 1.9.1 builds of Lightning at <http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central>. Bug 481685 has more details for those who wish to keep up.

[Wim-bos-be (wim-bos-be)]

*** Bug 486818 has been marked as a duplicate of this bug. ***

[Huzaifas (huzaifas)]

(In reply to comment #96)
> (In reply to comment #92)
> > Since noone has yet been able to reproduce this bug on the trunk, removing
> > [tbneeds]. If someone does manage to reproduce it, please re-add that keyword!
> >
> > I wonder if the nsIThreadManager changes that happened after 1.8 are working in
> > our favor.
>
> I found one more difference. We never added the enhancement from bug 363455 to
> 1.8 branch, so TB 2 does not have it. That patch is meant to improve handling
> of blocking sockets. It would be interesting to know if it helps for this bug.
> I backported the patch, you find it in bug 363455 attachment 365683 [details].
> Would someone of you who is still using TB 2 be able to try that patch?

Used this patch for TB 2.
The Cal+mail performance is much better now.
Though i see cpu spikes now and then, but it does not hang my TB.

[Dmose (dmose)]

Thanks, Huzaifa, that's very helpful to know. Setting the version field appropriately, since there's no longer reason to believe that this bug applies to the trunk.

[Mk144210 (mk144210)]

You know I'm honestly wondering if its the same bug as I just turned mail checking back on and it still works. Maybe whatever the offending event in my calendar simply passed...

[Ssitter (ssitter)]

*** Bug 485649 has been marked as a duplicate of this bug. ***

[bvdbos (bvdbos)]

Perhaps someone could deliver 0.9.1 versions of lightning with the backported fix and the fix from bug 363455 comment 16 ?

[Lee-scalellc (lee-scalellc)]

(In reply to comment #26 and #17)

> does this happen on Windows only?

No, this is also a problem on TB 2.0.0.21 / Lightning 0.9 on Mac OS X 10.5.7

I've found that once it happens the only solution is to delete the https caldav calendar, quit TB then restart it, add the calendar back in.

I'm connecting to a Google Apps calendar.

[Mk144210 (mk144210)]

You are lucky. I can't get it to work even if I reimport Google Calendar. A fix would be very appreciated.

Misha

[Mschroeder-mozilla (mschroeder-mozilla)]

*** Bug 477088 has been marked as a duplicate of this bug. ***

[Mschroeder-mozilla (mschroeder-mozilla)]

*** Bug 483683 has been marked as a duplicate of this bug. ***

[John Pye (jdpipe)]

The bug is present on TB 2.0.0.23 on Linux Ubuntu 9.04.

I recently suffered serious data loss as a result of this bug. PLEASE PLEASE PLEASE could resources be allocated to applying this patch to current Thunderbird versions?

[Philipp-bugzilla (philipp-bugzilla)]

Given bug 363455, I think we can soon mark this bug as FIXED (by that bug). Leaving a couple of weeks grace period, please report if you can reproduce this on Lightning 1.0pre ONLY. We are aware that this is an issue for 0.9, but the only way to fix it would be to drive forward bug 363455's branch approval.

[Wolfgang Sourdeau (wsourdeau)]

(In reply to comment #111)
> Given bug 363455, I think we can soon mark this bug as FIXED (by that bug).
> Leaving a couple of weeks grace period, please report if you can reproduce this
> on Lightning 1.0pre ONLY. We are aware that this is an issue for 0.9, but the
> only way to fix it would be to drive forward bug 363455's branch approval.

I do not really agree with the above, especially since this bug has been marked as a 1.8-only bug. Even when Thunderbird 3 is released, people using Thunderbird 2 will still be stuck with it because it is ignored by its maintainers.

[Vijitnair (vijitnair)]

I have been able to reproduce this problem with TB 3.0b4 and Lightning 1.0pre (2009-10-27) nightly. OS - WinXP. I see the exact same symptoms - CPU usage goes to 50% (on a dual core machine). It takes 10-15 mins for TB to start. Even after this it is very sluggish. CPU usage keep fluctuating between 50%-20%.

If I disable Lightning, then TB starts up just fine. I have tried this over and over (back and forth) and am quite positive that Lightning is causing this hang.

I only have one IMAP account configured (without SSL). When the hang happens, there is not data traffic as connection to IMAP server is not available.

No WebDAV/CalDAV account has been configured. No google account has been configured.

[Ssitter (ssitter)]

(In reply to comment #113)
I don't think you are seeing this bug because you are not using remote calendars and no secured mail server. Lightning 1.0pre test builds have a known issue that causes the calendar database to grow uncontrolled. The big database causes a similar slowdown. See Bug 521408 -> Bug 494140.

[Kai Engert (kaie)]

I convinced the drivers to approve the backported patch from bug 363455 to the thunderbird 2 branch. I'll check it in soon and nightly builds will contain the fix.

I'd like to ask everyone experiencing this problem for a favor. Please get the nightly build and test it. The test manipulates some core communication code, and the decision makes were a bit scared to include this patch on a old stable branch.

So, we need to make this change really works. I'm looking forward to your understanding and testing.

I'll make another comment, once the builds are ready, with the link to the test builds.

Thanks.

[Kai Engert (kaie)]

Could you please test one of the builds named
  thunderbird-2.0.0.24pre.* (nightly prerelease builds)
from
ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/

and let us know how it works for you?

Is this bug solved for you?
Do you see any functional regressions (new bugs) when using POP3/SSL, IMAP/SSL, SMTP/SSL (or TLS)?

Thanks!

[Tmpjjl (tmpjjl)]

The problem is not corrected for me using the build referenced in Comment #116. Installed and started without trouble. Turned on "Check for new messages at startup" on three email accounts. Restarted and Thunderbird hung up using 100% of one processor. Not all calendars had loaded.

[Bugzilla-axel-naumann (bugzilla-axel-naumann)]

Same here: the bug is not fixed by thunderbird-2.0.0.24pre on win32. Enabling lightning 0.9 will make thunderbird 100% busy during startup, disabling it will revert to the expected startup behavior. Please let us know whether we should check for regressions nevertheless, or whether the patch will be reverted.

[Timporter (timporter)]

This has been the bain of my life recently, because my calendar has grown to a substantial size and takes a while to upload any new appointments.
If I edit an appointment too soon after editing another appointment I get 100% CPU, and worse, a truncated calendar is stored because the DAV upload is aborted!

Interupting this DAV upload process with any other kind of SSL traffic aborts the transfer and causes the deadlock. Worse, terminating the TB process then empties the remote ICS file.
TB 2.0.23
L 0.9

[Kelly-caudill (kelly-caudill)]

I have been using Thunderbird 2.x with Lightning for at least a year with no problems. I have several mail server accounts - all IMAP. My main/production mail server definition is set to use TLS on port 143 rather than SSL. My other mail accounts are mostly test and do not use TLS or SSL. I recently added a new production IMAP account which requires SSL (not TLS). And a new calendar which also requires SSL.

Last night I was prompted to allow TB to install 2.0.0.24. After restarting, TB now always goes to 100% CPU almost instantly - I have a few seconds to twiddle the UI before it hangs. If I am quick, I can get in and disable the lightning plugin. It is completely unusable unless I disable lightning.

[Kelly-caudill (kelly-caudill)]

So I now have 3 things that want to use SSL at the same time: my new IMAP account, my old calendar account and my new calendar account.

Lightning used to be very annoying about calendar passwords. It was constantly popping up to ask for my calendar password again and again. I don't know if that was because my old calendar server was horribly unreliable and therefore lightning was often having to reconnect or if this is just a design defect. But to avoid that hassle, I finally broke down and allowed it to remember my calendar password in the password manager. I did the same with my new calendar password. But not with any of my mail accounts.

I just removed all those passwords and enabled lightning again and am able to use mail. But if I give it the password instead of clicking cancel on both calendar login prompts, it hangs again.

[Timporter (timporter)]

(In reply to comment #120)

This bug is fixed in Thunderbird 3.x

[Wolfgang Sourdeau (wsourdeau)]

(In reply to comment #122)
> (In reply to comment #120)
>
> This bug is fixed in Thunderbird 3.x

Any chance of having this backported to 2.x ?

[Philipp-bugzilla (philipp-bugzilla)]

We won't be backporting this bug. Closing this bug for now, the original issue seems fixed. Note there may be other hangs with a different core problem, so please only reopen this bug if the issues mentioned here persist.