frequent hanging

Bug #386326 reported by Nick Lally on 2009-06-12
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
thunderbird (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: thunderbird

I am not sure if this should be a duplicate of bug #110836 or bug #144437 or bug #264993 or bug #150578

I am seeing frequent hangs of thunderbird. I have multiple, shared IMAP accounts configured and several times a day thunderbird will completely hang.
An strace shows only futex() activity. For what it's worth I've attached a gdb backtrace from a hung process.

Do you see any error messages in the Error Console?

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.

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.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: 2008031218

Erreur : [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.getRequestHeader]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///C:/Users/mdelorme/AppData/Roaming/Thunderbird/Profiles/lj3gm3xo.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calDavCalendar.js :: checkDavResourceType_oSC :: line 1287" data: no]
Fichier source : file:///C:/Users/mdelorme/AppData/Roaming/Thunderbird/Profiles/lj3gm3xo.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/js/calDavCalendar.js
Ligne : 1287

Reproducible: Sometimes

Steps to Reproduce:
1.happens very very often at startup

I restart 3 or more times thunderbird to make it not consume 100% of my CPU !!!
How could I've got more information
Actual Results:
lightning + thunderbird hangs
I'm _not_ using cached calendar
the CPU is 100% used
I noticed that when it hangs and I closed thunderbird its pop-up a message, "a security connection has not been closed properly"
It's hang as soon as lightning fetch calendar the cpu reach 100% and then hangs
until it has passed all calendars
What is stranged is that lightning fetch calendars disabled even when alarm are not to bee shown on this calendars

lightning + thunderbird hangs during 5mn at least with 23 caldav calendars

Expected Results:
lightning works properly as soon as I launch it

I've not real idea of what happens !!
I'm not sure that the error log is about that

What Thunderbird version do you use? What Lightning version do you use? What CalDAV server and version do you use?

Ligthning : Build Identifier: 2008031218
Thunderbird : version 2.0.0.12 (20080213)
Server : DavIcaL 0.9.1

Belong one of my calendar, I've got one that was cached so this bug is probably the same as 412914

Sorry for polluting BMO

*** This bug has been marked as a duplicate of bug 412914 ***

With
lightning :2008031318
Thunderbird : version 2.0.0.12 (20080213)
Server : DavIcaL 0.9.1

with _no_ cached calendars (this time I check carefully), lightning hangs at startup
Lightning doesn't connect anymore to DaviCAL, and can not send email !

How could I give more information ?

Sometimes it hangs sometimes not, but when it hangs its do not come back to a normal state

1) Do you have "Show Alarms" selected for your calendars? If so, does deselecting it (and restarting) have any effect?
2) Do you see anything in the error console? (you might want to create a new preference named calendar.debug.log and set it to true in order to get a bit more information)
3) Do you have access to the server logs? See anything there?

I confirm that id does not hang each time :-/
1) with or without alarms enable (for all my calendars) same result and same log
2) done no diffrence between hang or not
3) don't see anything particular

It seems more difficult to make it hangs when no "Show Alarms" checked

In order to get the error reported in the bug description, we're most likely getting an error back from the server that we're not handling. Any chance you could do a wiretrace and tell us what that error is?

With alarm activated, I succeed to make Lightning hangs
Error Console : lot of "refresh completed with status 207"
Aparche access_log : lot of
-----
82.227.98.214 - - [16/Mar/2008:14:19:55 +0100] "PROPFIND /cal/some_guy/home/ HTTP/1.1" 406
-----
suspect is to detect if the server support scheduling
then a lot of
-----
82.227.98.214 - mdelorme [16/Mar/2008:14:20:20 +0100] "OPTIONS /cal/some_guy/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12"
---------
and lot of
---------
82.227.98.214 - mdelorme [16/Mar/2008:14:20:53 +0100] "REPORT /cal/some_guy/home/ HTTP/1.1" 207 14180 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080213 Lightning/0.8 Thunderbird/2.0.0.12"
-----
apache error_log : nothing interesting there for REPORT query at least

I've the feeling (but that's just a feeling) that when the server does not answer in short of time, Lightning hangs

last time it's hang I got this on apache Log
the console log was stuck on :
itemUri.spec = https://www.tennaxia.net/cal/mdelorme/home/db56b625-4196-41af-8f7c-fb74c0cbc63d.ics

And Apache access log :
82.227.98.214 - - [22/Mar/2008:11:29:02 +0100] "GET /cal/mdelorme/home/db56b625-4196-41af-8f7c-fb74c0cbc63d.ics HTTP/1.1" 401 1519 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"
82.227.98.214 - mdelorme [22/Mar/2008:11:29:07 +0100] "GET /cal/mdelorme/home/db56b625-4196-41af-8f7c-fb74c0cbc63d.ics HTTP/1.1" 404 28 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

And the event doesn't exists

(In reply to comment #11)
> 82.227.98.214 - - [22/Mar/2008:11:29:02 +0100] "GET
> /cal/mdelorme/home/db56b625-4196-41af-8f7c-fb74c0cbc63d.ics HTTP/1.1" 401 1519
> "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.8.1.12) Gecko/20080201
> Firefox/2.0.0.12"

This not Lightning accessing a file on your server. That's your browser.

you're right, seeing that it hangs there, I try to GET it by FF, my mistake :-/

It's very inconvenient, I need to restart 3 or more time Tb to make it not hang.
Is there something I can do to help ?
I'am a bit familiar with Eclipse, Javascript, Firebug ...

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.

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.

One on my coworker in my compoany, since ligthning 0.8 with caldav calendar, has experince also a hang.
No error log. the connexion between thunderbird + lightning with external server seems cut

all of my coworkers are impact by this, their cpu is used 100%
We are now manually downgrading all of them to lightning 0.7
Is a very serious regression, I think
If I can help tell me what we can do, but I assure you that their a really big problem here
Ligthning : 0.8
Thunderbird : version 2.0.0.12 (20080213)
Server : DavIcaL 0.9.1
This bug in not UNCONFIRMED as all of my employees as the same bug !

More investigation for 0.9 is wanted.

I haven't been able to reproduce this myself, but I'm reasonably certain that it's caused by attempting to fetch&parse multiple large CalDAV calendars at startup, since we now fetch the entire calendar into a memory cache then. We'll probably want to serialize those initial loads to avoid the CPU spike Maxime is reporting, possibly through a calICalDavSiteManager interface though I'd prefer to avoid that if possible. It would also be good to have the ability to do that initial load from a local CachedCalendar if present so that we only need to go to the net for deltas.

It's possible that this is partly an issue with the webdav extension, so I'd be curious if the patch proposed in bug 416239 made any difference.

I am having the same problem (at least I think so), using the same Software (DavIcaL) with Thunderbird and Lightning.

I did a quick an dirty Test with Thunderbird 3 and the latest Lightning Nightly. The calenders did not show up, either, but the high CPU load was gone.

What puzzled me was that if you delete the calenders from Lightnings list, restart Thunderbird and resubscribe to the calenders, they show up instantly and correctly.

The DavIcaL and Lightning logs did not show anything at all. Lightning only said the server did not support scheduling.

Maxime, is Thunderbird configured to automatically download new email when Thunderbird starts? Do you use a secure connection (e.g. SSL) to your email server? What happens if you don't automatically check for new email when Thunderbird starts, does the problem disappear?

I'm thinking that this could be the same as bug 390036 and bug 428522.

I'm not sure that Lightning 0.8 is causing the problem. As I reported in one of those bugs, Lightning 0.7 can also show this behavior.

(In reply to comment #20)
> I'm thinking that this could be the same as bug 390036 and bug 428522.
>
> I'm not sure that Lightning 0.8 is causing the problem. As I reported in one
> of those bugs, Lightning 0.7 can also show this behavior.
>

Interesting. Maxime's original report of this bug did coincide rather precisely with a major change to the CalDAV provider that caused increased startup loads, but I suppose that could be a red herring. Since at least one and I think probably both of the bugs Pete cites involved ICS calendars, not CalDAV, I have to wonder if the patch proposed in bug 416239 would make a difference: if so that would point a finger at the webdav extension. Good to know even if we don't decide to accept that patch.

The error cited in the bug description here is caused by the CalDAV provider trying to fish the WWW-Authenticate header out of the reponse to a PROPFIND request, and failing. That header kind of really ought to be there at that point, and we've had other reports of odd things happening wrt authentication with DAViCal (bug 423767, bug 428034) so it's possible this is a DAViCal issue rather than a Mozilla one. It would be helpful if someone could wireshark the interaction leading up to this error.

(In reply to comment #20)
> Maxime, is Thunderbird configured to automatically download new email when
> Thunderbird starts?
YES
> Do you use a secure connection (e.g. SSL) to your email
> server?
YES
> What happens if you don't automatically check for new email when
> Thunderbird starts, does the problem disappear?
Can test it anymore ( see further ), but when I got this pb even if I restart and no mails was downloaded the bug appears
>
> I'm thinking that this could be the same as bug 390036 and bug 428522.
looks very same
>
> I'm not sure that Lightning 0.8 is causing the problem. As I reported in one
> of those bugs, Lightning 0.7 can also show this behavior.
In my case it never happens with 0.7
(In reply to comment #19)
> I haven't been able to reproduce this myself, but I'm reasonably certain that
> it's caused by attempting to fetch&parse multiple large CalDAV calendars at
> startup, since we now fetch the entire calendar into a memory cache then
You should be right, because my administrator (it's not me anymore) has put all 2007's events in a calendar backup, so my current calendar is much smaller and no more bug anymore

The error message is also reported in Bug 429329 / Bug 428034. Same issue?

On my system A (Ubuntu 8.04 + Thunderbird 2.0.0.14 + Lightning 0.8 + Provider for Google Calendar 0.4) Thunderbird hangs at startup,
on my system B (WinXP SP2 + Thunderbird 2.0.0.14 + Lightning 0.8 + Provider for Google Calendar 0.4) Thunderbird work fine.

This is for specifiyng that I'm not using DavCal but Provider for Google Calendar, and one of my systems hangs in 80% of starts

Multiple users have reported this issue at Oracle.

I've been able to reproduce this issue multiple times on Windows XP SP2 with Thunderbird/2.0.0.14 setup with an IMAP account configured to use SSL and Lightning/0.8 setup with a CalDAV calendar configured to use HTTPS. The IMAP server and CalDAV server were on the same host (i.e., same host name).

The problem would occur when Thunderbird is accessing the IMAP server at the same time that Lightning is accessing the CalDAV server. A timing issue!

We've been able to reproduce the issue consistently by monitoring the CalDAV exchange in HTTPAnalyzer and clicking on the IMAP Inbox at just the right time (!) for the IMAP connection to be established in between the CALDAV:calendar-query REPORTs and the CALDAV:calendar-multiget REPORTs.

Most of the users that have reported this issue had Thunderbird configured to check for new messages at startup which would increase the likelihood that the IMAP connection is established at pretty much the same time as the CalDAV connection. That being said, on my machine (Dell Latitude D630, Intel Core2 Duo CPU, Windows XP SP2) the issue was easier to reproduce without checking for new messages at startup automatically, but rather by clicking on the IMAP Inbox at just the right time.

From what we've seen the size of the IMAP Inbox, or the number of calendar components in the CalDAV calendar collection didn't matter so much. That being said, their respective size would surely influence the time it takes the server to return its responses (and thus impact the timing between the IMAP and CalDAV access).

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.

(In reply to comment #25)
So it's indead the same as Bug 390036 but for CalDAV? See Comment #20 above.

(In reply to comment #26)
> (In reply to comment #25)
> So it's indead the same as Bug 390036 but for CalDAV? See Comment #20 above.
>

Indeed.

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.

This seems like pretty serious failure mode; requesting blocking.

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

Resolving as duplicate per Comment #22 and Comment #27.

*** This bug has been marked as a duplicate of bug 390036 ***

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

Confirming per duplicates.

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

74 comments hidden view all 154 comments

Thanks Stefan!

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

Are you saying the problem is gone?

Created an attachment (id=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.

(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.

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.

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

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.

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 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.

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?

(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.

(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?

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.

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

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.

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

(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.

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.

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...

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

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

Nick Lally (nick-lally) wrote :

Binary package hint: thunderbird

I am not sure if this should be a duplicate of bug #110836 or bug #144437 or bug #264993 or bug #150578

I am seeing frequent hangs of thunderbird. I have multiple, shared IMAP accounts configured and several times a day thunderbird will completely hang.
An strace shows only futex() activity. For what it's worth I've attached a gdb backtrace from a hung process.

Nick Lally (nick-lally) wrote :

(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.

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

Misha

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

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

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?

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.

(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.

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.

(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.

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.

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!

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.

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.

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

Nedenom (nedenom) wrote :

If you happen to be using the Lightning add-on with a remote calendar over https together with an e-mail account over https it could be this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=390036.

gf (gf-interlinks) wrote :

Hi Nick,
Thank you for having taken the time to report a problem with Ubuntu and Thunderbird. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.

You made this bug report in 2009 regarding Thunderbird and there have been many changes in Ubuntu since that time. Your problem may have been fixed with some of the updates.

Could you confirm that this is no longer a problem and that we can close the ticket?

Or, if it still might be a problem, it would help us a lot if you could test it on a currently supported Ubuntu version. When you test it and it is still an issue, kindly upload the updated logs by running only once:
apport-collect 386326

and any other logs that are relevant for this particular issue.

G

Changed in thunderbird (Ubuntu):
status: New → Incomplete
Paul White (paulw2u) wrote :

Bug report didn't close due to bug watch
No reply to gf's request for information after 6 months
Previously no comments on report since 2010
Initial report fails to mention Ubuntu or Thunderbird versions but clearly both EOL
Marking "Invalid" to close and reduce backlog

Changed in thunderbird (Ubuntu):
status: Incomplete → Invalid
Displaying first 40 and last 40 comments. View all 154 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.