GNOME Bugzilla – Bug 597157
crashes e-calendar-factory on multiple EDataCal requests
Last modified: 2013-09-13 01:07:04 UTC
Version: 2.30.x What were you doing when the application crashed? I had just switched to the calendar. All my calendar entries didn't show up. I'd deactivated on of them (On this Computer -> Work) and then reactivated it. Here we are. I'm running today's git master. Yesterday's didn't have this problem. I'm going to purge all the datatabases and restart, this often works. Distribution: Slackware Slackware 12.2.0 Gnome Release: 2.28.0 2009-09-21 (GARNOME) BugBuddy Version: 2.28.0 System: Linux 2.6.31.1 #44 SMP PREEMPT Tue Sep 29 12:17:33 EDT 2009 i686 X Vendor: The X.Org Foundation X Vendor Release: 10799001 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: gnome GTK+ Modules: gnomebreakpad Memory status: size: 247320576 vsize: 247320576 resident: 80379904 share: 30892032 rss: 80379904 rss_rlim: 18446744073709551615 CPU usage: start_time: 1254506857 rtime: 7603 utime: 6973 stime: 630 cutime:67 cstime: 21 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/garnome-svn-2.28/bin/evolution' [?1034h[Thread debugging using libthread_db enabled] [New Thread 0xb5eeb710 (LWP 11843)] [New Thread 0xaf620b90 (LWP 1671)] [New Thread 0xafe8fb90 (LWP 11873)] [New Thread 0xb0778b90 (LWP 11872)] [New Thread 0xb0f78b90 (LWP 11856)] [New Thread 0xb1778b90 (LWP 11855)] [New Thread 0xb2dd8b90 (LWP 11854)] [New Thread 0xb35d8b90 (LWP 11853)] 0xb61af171 in waitpid () from /lib/libpthread.so.0
+ Trace 218008
Thread 1 (Thread 0xb5eeb710 (LWP 11843))
---- Critical and fatal warnings logged during execution ---- ** libecal **: e_cal_view_start: assertion `view != NULL' failed ** evolution **: dbus_g_proxy_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** libecal **: e_cal_view_start: assertion `view != NULL' failed ** evolution **: dbus_g_proxy_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** GLib-GObject **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed ** libecal **: e_cal_view_start: assertion `view != NULL' failed ** evolution **: dbus_g_proxy_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed ** evolution **: dbus_g_proxy_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed
I purged the database etc. files from ~/.evolution. Restarting evo gives the calendars (without the work one that the previous crash was involved with). Switching to another date shows a blank calendar; worse reactivating the work calendar leads to another crash.
Are you getting crash after calendar dbus code got merged in master ? It was merged on Oct 2, 2009.
It seems to be regression of dbus changes. I am also getting similar crash now.
Yes, me too (happened last night in fact).
Created attachment 144817 [details] [review] proposed eds patch for evolution-data-server; Confirming. The e-calendar-factory process (the replacement of evolution-data-server-X-YZ process, together with e-addressbook-factory process) crashed, and took with itself also evolution. Please give a try to this patch. Thanks in advance.
The patch applies and compiles fine; so far no crash. Thanks Milan
I got a crash after applying the patch. It's not always reproducible. ** (evolution:26455): CRITICAL **: dbus_g_proxy_call: assertion `!DBUS_G_PROXY_DESTROYED (proxy)' failed Program received signal SIGSEGV, Segmentation fault. 0xb7b81c8a in e_cal_new (source=0x80b5f60, type=E_CAL_SOURCE_TYPE_JOURNAL) at e-cal.c:758 758 g_warning ("Cannot get cal from factory: %s", error->message); (gdb) t a a bt
+ Trace 218087
Thread 1 (Thread 0xb63aa720 (LWP 26455))
Comment on attachment 144817 [details] [review] proposed eds patch Created commit 937382d in eds master (2.29.1+) I committed it anyway, let's try to figure out the issue after that.
Akhil, which source is this about? Just as a starter (gw/eex/local/...). I know it's from memos, but nothing else. Also, this can be partially fixed in a very same way as you did a partial fix yesterday, on other place. I believe the 'error' is NULL, thus error->message seg-faults. Feel free to commit same partial fix, and maybe close this bug, as we are not able to get steps to reproduce. We can return to it in other bug (to not steal this one). Thanks in advance.
Created attachment 144971 [details] [review] proposed eds patch for evolution-data-server; Note this is for error->message crash, not for the "Out of memory" crash. I was able to reproduce this when I didn't compile weather calendar backend in eds and tried to enable weather calendar in evo. The e-calendar-factory process crashed, thus the function call failed, but the error wasn't set. I added couple of other code to properly report errors from cal factory to evo. Also, dbus signal names were incorrect here, there shouldn't be '-' in them.
The patch builds and installs. The calendar now shows all the expected entires and toggling the weather calendar on & off behaves as expected.
OK something is wrong. I built/reinstalled with Milan's latest (comment 11). The calendar behaved properly until I added a new appointment. The appointment appears twice in the calendar. What's worse, is that when I deactiveate that calendar (a local calender called Work here) only one of the entries goes away. The other is still present (showing the default color of the Work calendar). Reactivating Work results in the entries being doubled. Note that the problem seems to be for all entries in the work calendar, not just the new one. Other local calendars are ok, but then I've not added anything to them (yet).
running evolution --force-shutdown and then purging all the .db files seems to fix this. Until I add a new appointment.
The issue with doubled appointments is sort of known (maybe not reported yet) on master, and was there even before my patch. It's enough to close and run evolution again, no need for cache flush.
Created commit 518975c in eds master (2.29.1+) (for the second patch) I take this bug as fixed and I created bug #597778 for the doubled events issue.