GNOME Bugzilla – Bug 655986
file backend: e_cal_create/remove_object problems
Last modified: 2011-08-10 16:16:25 UTC
SyncEvolution 1.1.99.5 + Evolution Data Server from gnome_2_32 branch (8127525268c617367b8a443c203f468280399cd2). Run Client::Source::eds_event::testLinkedItemsChildParent. e_cal_get_object() and thus the test fail with "Object not found" although the UID is one reported by e_cal_get_object_list() earlier. This occurs because the internal hash contains an entry where the key doesn't match the UID of the component contained in it: e_cal_get_object_list() reports the UID, which then isn't found in the hash. valgrind on e-calendar-factory: ==10069== Invalid read of size 1 ==10069== at 0x4C25812: __GI_strlen (mc_replace_strmem.c:284) ==10069== by 0x8EF011E: g_strdup (gstrfuncs.c:99) ==10069== by 0xF4E08B6: e_cal_backend_file_create_object (e-cal-backend-file.c:2363) ==10069== by 0x93E6061: e_cal_backend_sync_create_object (e-cal-backend-sync.c:214) ==10069== by 0x93E86D3: _e_cal_backend_create_object (e-cal-backend-sync.c:630) ==10069== by 0x93DD40B: e_cal_backend_create_object (e-cal-backend.c:1017) ==10069== by 0x93F0C34: impl_Cal_createObject (e-data-cal.c:401) ==10069== by 0x4E75383: _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT_STRING (e-gdbus-marshallers.c:377) ==10069== by 0x820999E: g_closure_invoke (gclosure.c:773) ==10069== by 0x8225972: signal_emit_unlocked_R (gsignal.c:3256) ==10069== by 0x82248D0: g_signal_emit_valist (gsignal.c:2997) ==10069== by 0x8224DBC: g_signal_emit (gsignal.c:3044) ==10069== Address 0x1499c7b0 is 0 bytes inside a block of size 39 free'd ==10069== at 0x4C240FD: free (vg_replace_malloc.c:366) ==10069== by 0x9DE952C: icalvalue_free (in /usr/lib/libical.so.0.44.0) ==10069== by 0x9DDB796: icalproperty_set_value (in /usr/lib/libical.so.0.44.0) ==10069== by 0x4E4FFA2: e_cal_component_set_uid (e-cal-component.c:1479) ==10069== by 0xF4DB8F3: check_dup_uid (e-cal-backend-file.c:498) ==10069== by 0xF4DBD9B: add_component (e-cal-backend-file.c:614) ==10069== by 0xF4E0894: e_cal_backend_file_create_object (e-cal-backend-file.c:2356) ==10069== by 0x93E6061: e_cal_backend_sync_create_object (e-cal-backend-sync.c:214) ==10069== by 0x93E86D3: _e_cal_backend_create_object (e-cal-backend-sync.c:630) ==10069== by 0x93DD40B: e_cal_backend_create_object (e-cal-backend.c:1017) ==10069== by 0x93F0C34: impl_Cal_createObject (e-data-cal.c:401) ==10069== by 0x4E75383: _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT_STRING (e-gdbus-marshallers.c:377) An explanation of how this happens will follow in the commit messages for the patches fixing the issue.
I have prepared patches against the gnome_2_32 branch, which is what I can test with at the moment. The same problems exist in the master and gnome_3_0 branches. I have not tested with a non-file backend. It would be good if someone with access to different backends could verify that e_cal_remove_object() with MOD_ALL works as intended.
Created attachment 193274 [details] [review] ecal file backend: avoid manipulating the UID inside component_add()
Created attachment 193275 [details] [review] calendar file backend: fixed incomplete sanity check in e_cal_create_object()
Created attachment 193276 [details] [review] libecal: e_cal_remove_object() must remove *all* recurrences
Created attachment 193467 [details] [review] [PATCH 1/3] ecal file backend: avoid manipulating the UID inside component_add() [MASTER]
Created attachment 193468 [details] [review] [PATCH 2/3] calendar file backend: fixed incomplete sanity check in e_cal_create_object() [MASTER]
Created attachment 193469 [details] [review] [PATCH 3/3] libecal: e_cal_remove_object() must remove *all* recurrences [MASTER] Ported all the patches to the master branch and updated the documentation accordingly (the new ECalClient documentation was conflicting with the change).
I can confirm that EDS master is also affected by the issue and that the attached patches make the Client::Source::eds_event tests pass.
I do not see any change while trying a test from evolution's UI, it seems to do the same with or without the patch, thus yes, please commit to master. (I tested master versions only, though feel free to commit to the 2.32 branch too.) I suppose it's because evolution is using views,which don't suffer of this inconsistency.
One thing I was afraid of was that the add_component is called from multiple places, but only on one you added the new UID generation. That's kinda strange and can, probably, lead to other issues, but as I wasn't able to reproduce it under calendar evolution UI, then I'm most likely wrong.
Applied the patches to master and cherry-picked into gnome-3-0 and gnome-2-32.