Error: "too much recursion" when quickly reloading remote calendars (calIStatusObserver, calendar-statusbar.js)

RESOLVED FIXED in 1.0b4

Status

Calendar
General
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: ssitter, Assigned: Fallen)

Tracking

({perf})

Trunk
1.0b4
x86
Windows XP
Bug Flags:
blocking-calendar1.0 +

Details

(Whiteboard: [needed beta][no l10n impact])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090525
Calendar/1.0pre

Steps to Reproduce:
1. Start Sunbird with new profile
2. Create some new calendars, e.g. open local ics files
3. Hold Ctrl+R to quickly reload remote calendars

Actual Results:
At the beginning the status bar shows something like "Loading calendar x of 4" with x = 1 to 4. Later it shows something like "Loading calendar x of 48" or "Loading calendar x of 4294967299". Error Console is flooded with "too much recursion" errors, for example:

An error occurred executing the calendar_reload_remote_calendars command

[Exception... "'[JavaScript Error: "too much recursion" {file: "file:///E:/sunbird/components/calCompositeCalendar.js" line: 356}]' when calling method: [calIStatusObserver::startMeteors]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///E:/sunbird/components/calCompositeCalendar.js :: cCC_refresh :: line 356"  data: yes]


Error: [Exception... "'[JavaScript Error: "too much recursion" {file: "file:///E:/sunbird/components/calCompositeCalendar.js" line: 457}]' when calling method: [calIStatusObserver::spinning]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///E:/sunbird/components/calCompositeCalendar.js :: anonymous :: line 457"  data: yes]

Error: Error getting cell props: [Exception... "'[JavaScript Error: "too much recursion" {file: "file:///E:/sunbird/components/calCompositeCalendar.js" line: 233}]' when calling method: [calICalendar::id]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: file:///E:/sunbird/components/calCompositeCalendar.js :: cCC_getCalendarById :: line 233"  data: yes]

Error: [Exception... "'[JavaScript Error: "too much recursion" {file: "chrome://calendar/content/calendar-statusbar.js" line: 135}]' when calling method: [calICalendar::id]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://calendar/content/calendar-statusbar.js :: cStObs_calendarCompleted :: line 135"  data: yes]
Duplicate of this bug: 507606
Is anything being done about this? It's making lightning unusable.

Comment 3

8 years ago
I've tested with and without the cache and I have those issues too.

It's quite easy to reproduce when you have many (6-8) large (500-1000 events) CalDAV calendars.
Flags: blocking-calendar1.0?
(Assignee)

Comment 4

8 years ago
It would be good to fix this for 1.0, since the solution seems to be to get rid of spinning the event loop. This means we need to move certain operations into threads, possibly the processing of the ical component.

I tried this and got hangs and segfaults. I also tried experimenting with nsIProxyObjectManager but this also fails the way I did it.
Flags: blocking-calendar1.0? → blocking-calendar1.0+
(Assignee)

Updated

8 years ago
Duplicate of this bug: 556992

Comment 6

8 years ago
It's very very annoying, can you fix this soon?
(Assignee)

Updated

8 years ago
Whiteboard: [needed beta][no l10n impact]
(Assignee)

Updated

8 years ago
Duplicate of this bug: 580785
(Assignee)

Comment 8

8 years ago
I've tried a bunch of things here, but I'm starting to run out of ideas. The goal is to move most of processIcalComponent into the thread. This would make the calls to calIcsParser fast enough that we can remove the call to processPendingEvents().


* Just move processIcalComponent into the worker thread
 -- Fails with lots of warnings that various components are not marked as 
    threadsafe. I've tried to make as many of them threadsafe as possible, but
    even so the events are not shown in the UI.
 -- Segfaults after a while

* Proxy all of calIIcsParser into the thread pool using nsIProxyObjectManager in the factory
 -- Fails, lots of UI stuff (including xul elements and nodes) seem to be 
    proxied into the thread pool

* I've removed everything out of the worker thread to find out where the actual problem is.
  -- The call to cal.createEvent causes thread warnings that suggest that
     nsIJSID is not threadsafe. This doesn't match with [1].


* Proxied the creation of event instances into the main thread by creating an extra component that only runs on main thread and returns instances of calIEvent.
  -- Fails with lots of warnings and segfaults.


Any other ideas?


[1] http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/xpcjsid.cpp#49
(Assignee)

Comment 9

8 years ago
I'll be looking into this starting tomorrow. I have a few new ideas, I hope it works out!
Assignee: nobody → philipp
Status: NEW → ASSIGNED

Comment 10

8 years ago
Thank you very much Phillip, because current nightly is impossible to use. I hope that your ideas are correct :)

Comment 11

8 years ago
Any idea? We need it :-)
(Assignee)

Comment 12

8 years ago
My ideas haven't been working out. We might consider just disabling threading for the meanwhile, until bug 566951 is fixed.
(Assignee)

Comment 13

8 years ago
Ok, threading has partially been moved to a ChromeWorker, see bug 624192. We still have calls that use processPendingEvents() though.

We might get away with using Chrome Workers in the providers too (in places we have been using processPendingEvents()) and just removing it in the other places.

I'm going to try that now.
(Assignee)

Comment 14

8 years ago
Created attachment 504234 [details] [diff] [review]
Fix - v1

Turns out we can't just move those loops into workers, since most of them access a calIEvent/calITodo. Our implementation seems not to be threadsafe, marking it as such throws errors on createInstance.

This patch just removes cal.processPendingEvents(), I tested it on trunk with a reasonable amount of events and I didn't see a notable performance difference with and without.

The ultimate solution would be that gecko allows us to hand off non-threadsafe events from the worker to the main thread. I'm working on nagging the right people here :)
Attachment #504234 - Flags: review?(mschroeder)
(Assignee)

Updated

8 years ago
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]

Comment 15

7 years ago
Can anyone tell me something about this?
When i see this blinking/reload and i'm working on events, thunderbird stops to work for a few seconds.. it's very very annoying. Is it only for me?
I can't understand if is fixed or not. 
I write that "i'm working on events" but not only this, everything i'm doing on TB is stopped, Thubderbird is freeze for a few seconds. I can't modify this behaviour or increase the time between the freeze. It's the same for all my customers, I understand that is a lightning problem.. but is there a workaround?
(Assignee)

Comment 16

7 years ago
Alessio, this is not necessarily an issue fixed by this bug. What version are you and your customers using? I recall there were issues when using imaps+https calendar, this may be fixed in current nightly builds. Also, if your calendars contain a lot of data, consider archiving old events to a different calendar.
(Assignee)

Comment 17

7 years ago
On a different note, I have a trunk only solution in the works that uses js generators to postpone some stuff, but it will require a bit more work since it also make the storage calendar asynchronous, but the cached calendar interface relies on it being synchronous.
(Assignee)

Updated

7 years ago
Blocks: 576017

Updated

7 years ago
Keywords: perf
(Assignee)

Updated

7 years ago
Duplicate of this bug: 583279
(Assignee)

Comment 19

7 years ago
Comment on attachment 504234 [details] [diff] [review]
Fix - v1

Ludovic, do you think you could take over review on this bug?
Attachment #504234 - Flags: review?(mschroeder) → review?(lmarcotte)
(Assignee)

Updated

7 years ago
Duplicate of this bug: 616124
Comment on attachment 504234 [details] [diff] [review]
Fix - v1

r=mschroeder. Let's wait for feedback (or hopefully no feedback) from nightly users. ;)
Attachment #504234 - Flags: review?(lmarcotte) → review+
(Assignee)

Comment 22

7 years ago
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/cafd2739fe9e>
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
(Assignee)

Updated

7 years ago
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
(Assignee)

Comment 23

7 years ago
Backported to comm-miramar <http://hg.mozilla.org/releases/comm-miramar/rev/a7d75ac8505a>
Target Milestone: Trunk → 1.0b4

Comment 24

7 years ago
Today I have installed the nightly build. All Calenders seem to be fine but the error messages still remains. 

Fehler: too much recursion
Quelldatei: file:///home/bwollny/.thunderbird/uk5zetiy.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calProviderUtils.jsm
Zeile: 606

Fehler: too much recursion
Quelldatei: file:///home/bwollny/.thunderbird/uk5zetiy.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/modules/calUtils.jsm -> file:///home/bwollny/.thunderbird/uk5zetiy.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js
Zeile: 813
(Assignee)

Comment 25

7 years ago
Hmm very disconcerting. Unfortunately there's not much we can do for the current release. Do you reproduce this using the same initial steps, or something different?
You need to log in before you can comment on or make changes to this bug.