GNOME Bugzilla – Bug 659732
Gnome fails to load and crashes when the Evolution-exchange plugin is configured
Last modified: 2011-09-21 23:05:48 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=739544 After some investigation, folks' eds backend crashes when ESource doesn't have a relative_uri set. The right value to use is ESource's UID, as it's a unique identifier among all ESources - the relative URI can repeat, only user can be different. The thing is that this crash in folks crashes gnome-shell, thus the session is not runnable. Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal 11, Segmentation fault.
+ Trace 228523
Thread 1 (Thread 0xb775c880 (LWP 2007))
Thanks for the report. We were under the false assumption that e_source_peek_relative_uri () was always non NULL (but still, some defensive programming could have been in place). We'll now be switching to e_source_peek_uid ().
On a second thought, this might not be that straight forward. We depend on the relative uri to configure the primary store, among other things (because it's an easy way to map address books). I'll investigate the possibility of using the absolute URI, but still this might have other implications.
Created attachment 197173 [details] [review] patch This is more a workaround than a proper fix. We should re-think on how we'd like to refer to ESources and decouple the relative URI from the PersonaStore id entirely if possibly (and tie the latter to the ESource's UID).
Review of attachment 197173 [details] [review]: Eep, this feels nasty. Why can't we just go with Edsf.PersonaStore.id = ESource.peek_uid() everywhere? I think we can get away with it because PersonaStore.id is defined as an opaque string, so it's not an API break.
ESources won't have URLs for much longer, so you'll be more future-proof by limiting how and where you use them. ESources should be uniquely identified by their UID string, which is permanent.
Here is a new take going for UID and leaving URIs aside: http://cgit.collabora.com/git/user/rgs/folks/log/?h=bgo-659732
Merged: commit 3b5f532c3975fb96a725f10d6cbf0b03b61f95fb Author: Raul Gutierrez Segales <rgs@collabora.co.uk> Date: Wed Sep 21 23:05:42 2011 +0100 eds: split up link-personas test and cut relative URI dependency Though some code might be duplicated, it's healthy to split tests into different executables to assure our clean-up code (wiping out GConf entries, shutting down our own session Bus, etc) runs between tests. Helps: https://bugzilla.gnome.org/show_bug.cgi?id=659732 commit 0ff740a9026592f723a6b219906a4823f2ec04fa Author: Raul Gutierrez Segales <rgs@collabora.co.uk> Date: Wed Sep 21 22:07:27 2011 +0100 eds: rework tests so that they don't depend on relative URIs Previously, tests were build around the assumption that each Edsf.PersonaStore had an id == ESource.relative_uri. That stopped being true (because you'll get swallowed by a black hole in pwithnall's garden if you use relative URIs). Helps: https://bugzilla.gnome.org/show_bug.cgi?id=659732 commit 73647bc63e66c085bf0a1a7080df9734734c77b7 Author: Raul Gutierrez Segales <rgs@collabora.co.uk> Date: Wed Sep 21 16:24:30 2011 +0100 e-d-s: use UID instead of relative URI to track ESources Some e-d-s backends (i.e.: the Exchange one) might not have a relative URI so we can't rely on it as an address book identifier. So from now on we use the ESource's UID. Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=659732