GNOME Bugzilla – Bug 504050
hang in calendar ...
Last modified: 2011-11-04 05:06:06 UTC
Was writing some mail and switched workspaces & back again, I guess I must have clicked 'Today' in the calendar somehow too; evolution hung permanantly: evolution: all threads quiescent except for this one:
+ Trace 182121
ie. e-d-s quiescent. *So* - it looks like e-d-s sent a reply, but evo. ignored / dropped it somehow - either that or e-d-s crashed in mid-request & was re-started [ also possible - but I got not bug-buddy ]. Either way, evo. should not hang (clearly).
I saw something similar with get_default_time_zone and it's already filled in the bugzilla (I do not have bug number handy at the moment), but I didn't see this in get_query yet. I guess this was just some coincidence, or are you able to reproduce it? I do not ask this because I want to get rid of this, but because I would like to know what kind of calendar this was, local/exchange/gw/... For example in case of exchange calendar, if exchange process crashes or something, then this will wait without a response or the main hang can be inside the exchange process (I guess). I committed some changes to recent SVN version of evolution-data-server related to queries (what a coincidence), but I do not expect any change in this particular thing, somehow. From the code, it seems it will not trigger the EFlag on backend error, so any operations can starve as this. I would really like to know whether you can recall (I know, it's sooo long ago), what occasions were during the hang.
get_default_time_zone happens frequently if you have a web calendar and hack the code to have 10 seconds refresh (have 2-3 cals). You can see it easily.
Finally I found the bug I was talking about, it is bug #501298 , my fault it's different function, e_cal_set_default_timezone. I'm still not sure what to do with this (original) one.
I cannot see any problem with e_cal_get_query at this point. I also tried to broke eds heavily, as Michael suggested, but even that evo passed without any harm. The only way I could let evo freeze was in code change to e-data-cal.c:impl_Cal_getQuery, when this function doesn't call e_data_cal_notify_query, then evo gets frozen. In case something really breaks, like SIGSEGV or something on eds side, then I think one cannot expect anything. Maybe just "will recover successfully", but I doubt the SIGSEGV can be recovered in this way. Similar for other critical runtime crashes. I noticed only some more-or-less unrelated changes here, http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8638 where we used other ref/unref method than was required for the work. I'm not sure how much related it is for this issue, probably not at all.
From further investigation on bug #501298, I realized that if eds crashes during such call as this (waiting for calendar response in main thread), then even a listener knows about the crash and is ready to notify evolution part, the evolution part will never notice, because such notice is delivered on idle, which cannot happen, because we are waiting on the response in the main thread. Nothing much to do with that, except of fixing the cause of trouble on eds side to prevent crashing it. On the other hand, if there was no problem with eds (aka it didn't crash), then there will be other issue. But as I said above, the code seems fine for this case. Any idea what to do with this?
Yes - that certainly sucks. No obvious solution lends itself to us - beyond the migration to d-bus; which we clearly should do.
Created attachment 123621 [details] [review] proposed evo patch for evolution; We can try this, meanwhile moving to dbus. It's similar like a thread pool in gnome-cal.c, we only updates view in a thread to not block main thread. Please review carefully, I've such a feeling it can have some issues with threading, because ECalModel doesn't seem to be thread-safe. Also, this tries to fix this particular place only, not every possible place in evo's calendar code. :) Nonetheless, it seems to work fine to me, at least it doesn't freeze for ever on the eds crash, only unchecks all calendars and continues its job.
I think we should wait for the dbus-port which would be the right solution for the issue. Ross has already started it. It should be there in GNOME 2.28. We can fix a lot of these issues in the right way with the same.
ping, dbus has been landed in 2.29.x, we can think about fix once again :-)
chen, ping, can we look for right solution as dbus has been merged ?
Yes definitely and we have more things to be worked for stability with dbus itslef...
I think this is not valid anymore, at least for 3.1.92 with EClient rewrites. Could you test it with that or any later version, please?
Please feel free to reopen this bug if the problem still occurs with a newer version of Evolution 3.2.1 or later.