Skip to content

SyncEvolution: A Bad Weekend – for Bugs!

This weekend saw the most gruesome death of several bugs which have affected SyncEvolution users with Evolution 2.12 and the iPhone. I don’t know whether any of these bugs were screaming “Today is a good day to die!” before gobbling their last byte, but some really put up a fight. Let me summarize what I fixed this weekend. Some changes are more like improvements, but in both cases it means that SyncEvolution 0.7 is a step closer. I’ll release a pre2 update soon; stay tuned and watch this blog.

Starting with Evolution 2.12 SyncEvolution crashed the Evolution Data Server when synchronizing calendars.

Once I managed to compile Evolution 2.12 on my Debian Etch desktop and also solved some linking problems, it turned out to be reproducible with the SyncEvolution test suite. Lesson one: test against Evolution development builds regularly.

After Matthew Barnes pointed me in the right direction, stepping through the code in the debugger showed that a change in e_cal_create_object() caused the problem: it failed because the event (identified by its UID) already existed. In contrast to previous versions, Evolution 2.12 removes the offending UID, so when SyncEvolution called e_cal_update_object() that call then failed even worse by crashing the back end due to an unchecked NULL UID pointer. Reconstructing the UID was an easy solution for this, once the reason was found. Lesson two (not really a new one, but always good to remember): don’t depend on unspecified behavior, it can change. If only it was more obvious which behavior is intentional and which isn’t ;-/

SyncEvolution hangs when the Evolution Data Server dies.

When the Evolution Data Server died, SyncEvolution remained stuck in the blocking EDS API calls because they do not return. The Evolution API documents a "backend-died" signal. Trying to catch that signal in SyncEvolution did not work at first; more investigations showed that the signal is only delivered to “normal” GNOME/glib applications which run an event loop. As a command line tool SyncEvolution did not have that and therefore the signal was never delivered. Now a background thread drives the event loop and SyncEvolution detects the problem. Because the API calls still don’t return with an error, all it can do is print an error and abort, but that’s still better than just keeping the user waiting… forever.

SyncEvolution segfault after updating to Ubuntu

Two users reported this. Stack back traces reported by the users pointed to an invalid free() in libcurl, but it never became clear what caused the memory corruption. There is no real solution, only a workaround. A configuration change seemed to help: if you follow an old Ubuntu forum post for compiling SyncEvolution from source (like one of the users did), then the configuration created as described in that forum does not enable a message size limit and the splitting of large objects. This was added in 0.5 and made the default in 0.6. Because upgrading to a more recent Evolution does not update the user’s .sync4j configuration files, these changes must be applied manually – the NEWS file will describe such changes. In this case the spds/syncml/config.txt should contain the following entries:

# The maximum size of each message can be set (maxMsgSize) and the
# server can be told to never sent items larger than a certain
# threshold (maxObjSize). Presumably the server has to truncate or
# skip larger items. Finally the client and server may be given the
# permission to transmit large items in multiple messages (loSupport =
# large object support).
maxMsgSize = 8192
maxObjSize = 500000
loSupport = 1

Note that SyncEvolution 0.7 pre1 is available as .deb in an apt repository that works for Debian and Ubuntu. You’ll only need to compile from source if you want it for 64 bit or some other platform.

Synchronization of photos with iPhone

Sending photos had been tested, but apparently not importing them – as one user reported, it just crashed. To cut a long story short, the API for photo import/export is different on the iPhone than on Mac OS X: the iPhone stores photos in different resolutions so that thumbnails load quicker. The API was extended to support this functionality and takes additional parameter that SyncEvolution did not pass. Now SyncEvolution calls the functions correctly, but it does not yet produce thumbnails when importing photos. If you can, scale down photos before adding them to contacts – it helps to keep the load on SyncML servers small and complete syncs faster. Note that despite the possibility to “move and scale” a photo on the iPhone before setting it, the photo will be stored in its original size! SyncEvolution will send the original size because otherwise the original photo might get lost when reimporting the contact. I try to avoid data loss under all circumstances, but am less sure about this case. If you think that the iPhone client should reduce the amount of network communication by only sending smaller photos, then please let me know.

ScheduleWorld and iPhone: vCard 3.0 import did not map phone numbers correctly

The preferred format of ScheduleWorld is vCard 3.0. Clients should use the card3 URI to get contacts in that format and also send them. The example configs of SyncEvolution 0.7 pre1 had card3 but contacts where always sent as vCard 2.1 because myFUNAMBOL is more happy with that format. Even worse, there was a bug in SyncEvolution’s vCard 3.0 parser which did not correctly detect the type of incoming phone numbers, therefore mapping most of them to “other”. The next release fixes that and also sends contacts as vCard 3.0 when configured for card3 (a hack, but there is no better way to detect the intended format at the moment). After the next update it is recommended to do a “refresh-from-server” sync to fix the broken types. Currently this has to be done by setting “sync = refresh-from-server” in the source’s config.txt, sync, reload the file and set “two-way” again. I’ll try to add a command line option to pre2 which will temporarily override the synchronization mode – I’m just not sure yet whether I should delay the update because of that.

Post a Comment

Your email is never published nor shared. Required fields are marked *