Closed Bug 422618 Opened 12 years ago Closed 12 years ago
lightning hangs at startup
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:188.8.131.52) Gecko/20080201 Firefox/184.108.40.206 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
Component: Provider: GData → Provider: CalDav
OS: Windows Vista → All
QA Contact: gdata-provider → caldav-provider
Hardware: PC → All
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 220.127.116.11 (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
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 412914
With lightning :2008031318 Thunderbird : version 18.104.22.168 (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 ?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Sometimes it hangs sometimes not, but when it hangs its do not come back to a normal state
Summary: lightning hangs at startup during 5 mn → lightning hangs at startup
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 ----- 22.214.171.124 - - [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 ----- 126.96.36.199 - 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:188.8.131.52) Gecko/20080213 Lightning/0.8 Thunderbird/184.108.40.206" --------- and lot of --------- 220.127.116.11 - 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:18.104.22.168) Gecko/20080213 Lightning/0.8 Thunderbird/22.214.171.124" ----- 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 : 126.96.36.199 - - [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:188.8.131.52) Gecko/20080201 Firefox/184.108.40.206" 220.127.116.11 - 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:18.104.22.168) Gecko/20080201 Firefox/22.214.171.124" And the event doesn't exists
(In reply to comment #11) > 126.96.36.199 - - [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:188.8.131.52) Gecko/20080201 > Firefox/184.108.40.206" 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 :-/
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 220.127.116.11 (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
On my system A (Ubuntu 8.04 + Thunderbird 18.104.22.168 + Lightning 0.8 + Provider for Google Calendar 0.4) Thunderbird hangs at startup, on my system B (WinXP SP2 + Thunderbird 22.214.171.124 + 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/126.96.36.199 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.
This seems like pretty serious failure mode; requesting blocking.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Resolving as duplicate per Comment #22 and Comment #27.
Status: NEW → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 390036
You need to log in before you can comment on or make changes to this bug.