User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729) Build Identifier: Lightning 1.0b2, Thunderbird 3.1.2, Google Calendar provider 0.7 Lightning freezes my Thunderbird every time it syncs the calendar or every minute or so of Thunderbid usage. This frozen times last for 3-5 secs and eat 100% of CPU. Disabling both extensions (Google provider and Lightning) eliminates the problem. Functionality is good: no data loss, no errors. Just this annoyance Reproducible: Always Steps to Reproduce: 1. Switch to TB for composition or reading 2. Wait for 10 to 30 secs Actual Results: Composition pane is frozen. Can't close or switch tabs, nor open, writing, scrolling. Nothing. Expected Results: No frozen times! Lightning 1.0b1 had the same behavior.

I am seeing exactly the same behaviour. The system is not usable while google sync is in progress.

Seba, Martin, is this still an issue using the recently released Lightning 1.0 (compatible with Thunderbird 8) and Provider for Google Calendar 0.9?

Will try. I'm on 9.0 now.

Seba, any update on this since you are now using Thunderbird 9 and Lightning 1.1.1?

I'm having a very similar problem, however, mine freezes for about 30-60 seconds where CPU utilization is near 100%. Memory usage shoots up to 500-600MB. Normally it's normally around 150-200MB. I have not timed it but it seems to happen every couple of minutes. With Provider for Google disabled, things seems to be working OK. I'm hoping this gets resolved soon...I really depend on Google calendar a lot! OS: WinXP Thunderbird: 10.0.1 Google Addon: 0.9 Lightning: 1.2.1

I'm hitting this hard during start and quite frequent during use with TB 11.0.1 & lightning 1.3. I also see a lot of sqlite calls of COMMIT TRANSACTION and BEGIN DEFERRED from Connection::BeginTransaction() and Connection::CommitTransaction() It could take few minutes before the UI react again. Attaching some stack trace from JS.

there are lots of reports like this on getsatisfaction

Can we get a stack trace from those GS users ?

(In reply to Ludovic Hirlimann [:Usul] from comment #8) > Can we get a stack trace from those GS users ? perhaps. but someone would need to contact them. not for me - as Im' nota calendar user. perhaps roland, Bas, Klonos or some other kind folk would do so.

there's allso the possibillity that this bug is a duplilcate

Compare bug 753343

I'm on TB 13 and Lightning said it's not compatible. I forced the installation and TB works but Lightning is not reading the calendar. :(

Testing Lightning 1.5b1 under TB 13. It works and reads the calendar successfully.

Seba, this is a different issue. The problem described here still exists.

I used Lightning 1.5b1 and Google Calendar Provider 0.13 for a week. The issue is still present but Thunderbird freezes for less time (1-3 secs). The cache function alleviates the delay to show the information when entering the calendar tab.

Certainly same problem here: http://www.geckozone.org/forum/viewtopic.php?f=4&t=105197&p=690191#p690191 Could you described what would be needed to get a usefull stack trace for understanding the problem?

ludo, this isn't google data, because I don't use that and see the same bug.

I um using TB 13 and Lightning 1.5 on a Linux machine (Arch Linux). TB freezes every now and then for about one minute or more. I couldn't see a difference when turning caching on or off. Turning it off just got me more calendar requests on the server. Please tell me if and how I can assist with more information/logs/etc. Unfortunately, TB is only usable for me without Lightning. I would really like to use it, though.

Getting the same stalling symptoms on TB 17.0.5 and Lightning 1.9.1 on Ubuntu 12.04.

(In reply to Jan Horak from comment #6) > Created attachment 617490 [details] > js stack trace > > I'm hitting this hard during start and quite frequent during use with TB > 11.0.1 & lightning 1.3. I also see a lot of sqlite calls of COMMIT > TRANSACTION and BEGIN DEFERRED from Connection::BeginTransaction() and > Connection::CommitTransaction() > It could take few minutes before the UI react again. > > Attaching some stack trace from JS. if you are still seeing the problem https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Thunderbird_Performance_Problem_with_G will be more interesting (assuming we have calendar symbols)

Reproduction: 1. Add 6 ICS calendars to Lightning, as local file (file:/// URLs to ICS files) 2. Add several meetings, including recurring meetings, to the calendars 3. Let it run for a week Actual result: multi-second freezes all the time, dog slow, unusable Expected result: No slowdown over time at all Cause: My guess is that Lightning uses too many JS objects and there's a weakness in the JS GC in mozilla. I see the same with some other extensions (e.g. Header Tools Lite) that process lots (MBs) of data in JS.

It's quite unclear whether the OP requires Google Calendar Provider for reproduction. But it is part of their description. And neither Martin nor Seba's reports indicate high memory usage.