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

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Stefan Sitter [:ssitter]]

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]

Comment 2

[Campbell-Lange Workshop]

Is anything being done about this? It's making lightning unusable.

Comment 3

[Ludovic Marcotte]

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.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 6

[Alessio]

It's very very annoying, can you fix this soon?

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

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

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

I'll be looking into this starting tomorrow. I have a few new ideas, I hope it works out!

Comment 10

[Michal Bruncko]

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

Comment 11

[Alessio]

Any idea? We need it :-)

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

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

Comment 13

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

Attachment: 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 :)

Comment 15

[Alessio]

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?

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

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.

Comment 19

[Philipp Kewisch [:Fallen][📱📆]]

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

Ludovic, do you think you could take over review on this bug?

Comment 21

[Martin Schröder [:mschroeder]]

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

r=mschroeder. Let's wait for feedback (or hopefully no feedback) from nightly users. ;)

Comment 22

[Philipp Kewisch [:Fallen][📱📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/cafd2739fe9e>
-> FIXED

Comment 23

[Philipp Kewisch [:Fallen][📱📆]]

Backported to comm-miramar <http://hg.mozilla.org/releases/comm-miramar/rev/a7d75ac8505a>

Comment 24

[Bernd Martin Wollny]

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

Comment 25

[Philipp Kewisch [:Fallen][📱📆]]

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?