GNOME Bugzilla – Bug 488881
Evolution-data-server crashes when running syncevolution
Last modified: 2008-07-03 16:58:26 UTC
Steps to reproduce: 1. Run evolution 2. Run syncevolution Stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224643696 (LWP 11114)] 0xb7812af7 in g_str_hash () from /usr/lib/libglib-2.0.so.0 (gdb) thread apply all bt
+ Trace 171850
Thread 6 (Thread -1224643696 (LWP 11114))
Other information: Here's the output when running e-d-s from a terminal and then syncevolution in another: juha@oskar ~ >evolution --force-shutdown Shutting down evolution-data-server-1.12 (Evolution Calendar file and webcal backend / Evolution Addressbook file backend) Shutting down evolution-alarm-notify (Evolution Calendar alarm notification service) juha@oskar ~ >/usr/lib/evolution/evolution-data-server-1.12 evolution-data-server-Message: Starting server e-data-server-Message: adding type `ECalBackendFileTodosFactory' e-data-server-Message: adding type `ECalBackendFileEventsFactory' e-data-server-Message: adding type `ECalBackendFileJournalFactory' e-data-server-Message: adding type `ECalBackendContactsEventsFactory' e-data-server-Message: adding type `EBookBackendGroupwiseFactory' e-data-server-Message: adding type `ECalBackendCalDAVEventsFactory' e-data-server-Message: adding type `EBookBackendLDAPFactory' e-data-server-Message: adding type `EBookBackendFileFactory' e-data-server-Message: adding type `EBookBackendVCFFactory' e-data-server-Message: adding type `ECalBackendHttpTodosFactory' e-data-server-Message: adding type `ECalBackendHttpEventsFactory' e-data-server-Message: adding type `ECalBackendHttpMemosFactory' e-data-server-Message: adding type `ECalBackendGroupwiseTodosFactory' e-data-server-Message: adding type `ECalBackendGroupwiseEventsFactory' e-data-server-Message: adding type `ECalBackendGroupwiseJournalFactory' e-data-server-Message: adding type `ECalBackendWeatherEventsFactory' in server_log_handler evolution-data-server-Message: Server up and running cal = 0x80568c0 cal = 0x8078f80 impl_GNOME_Evolution_Addressbook_BookFactory_getBook + file:///home/juha/.evolution/addressbook/local/system => 0x8078fb0 impl_GNOME_Evolution_Addressbook_Book_open (0x8078fb0) cal = 0x80568f0 impl_GNOME_Evolution_Addressbook_Book_getContactList sh: /usr/lib/libgnomeui-0/gnome_segv2: not found
I keep getting reports about this for SyncEvolution because SyncEvolution remains blocked in the synchronous libecal/libebook calls when the EDS dies, so for the user it looks like SyncEvolution just hangs. So far I have not been able to get a coherent overview of which Evolution versions are affected. There might even be different unrelated bugs causing it. Juha, thanks for filing this bug. The stack back trace hints towards memory corruption in the EDS process. Can you try again with evolution-data-server-1.12 running under valgrind? Just "apt-get install valgrind", then run "valgrind /usr/lib/evolution/evolution-data-server-1.12".
Created attachment 97700 [details] Valgrind output of e-d-s dying when running syncevolution
Patrick, Evolution 2.12 on gutsy is the first version I have encountered this with. SyncEvolution is 0.6, rebuilt on Gutsy after distribution upgrade from Feisty.
I was able to reproduce a crash by running the SyncEvolution test suite for calendars with a self-compiled Evolution 2.12.1. Contacts seemed to be okay. To reproduce it: * download syncevolution-0.7pre1.tar.gz from http://sourceforge.net/projects/sync4jevolution * configure CXXFLAGS=-g --disable-shared * make * cd src * make test * CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/runtests ./client-test Client::Source::ical20 Eventually the test hangs and the dataserver has crashed. Note to self: use this as test case for the (still to be written) code which detects that aborts SyncEvolution when the dataserver dies. I said "a crash" because I'm out of time not just for today and haven't even looked at a stack back trace. I won't have time before Sunday evening, more likely it'll be next week before I can look more closely. I'm not even sure I'd be able to fix it, so if someone from the Evolution team looks at this problem first that would very be much appreciated.
I did a little experiment while bored. I set "addressbook_1" to "refresh from server" in my syncevolution configuration and synced. EDS did not crash, and the sync was successful. Did the same for calendar_1 and todo_1, and it worked. After that, two-way sync works too. Meanwhile, I had built syncevolution 0.7pre-1, so I'm not quite sure which was the reason for success, upgrade or the one-time sync with "refresh-from-server". Anyway, it's working.
Juha, as far as I have seen so far it seems to be updating an existing calendar entry which crashes. Was that part of your two-way syncs?
Patrick, Actually I seem to have been hasty. Two-way syncs _do_ crash EDS if anything has changed. My success was due to there not being any. :-\ So no, any actual syncing of changes are still not allowed.
I have Evolution 2.12.x (compiled from the 2.20 branch with debug information, unfortunately optimization also was on) running now on my desktop. What I see is consistent with the stack backtrace reported above: a segfault in poll() from libc.
+ Trace 174458
Thread 2 (Thread -1259709520 (LWP 21996))
Okay, I found the reason. In Evolution 2.12.x the behavior of e_cal_create_object() for objects with a fixed UID has changed. Previously the call would fail if the UID was already used and then SyncEvolution falls back to updating that object, roughly like this: if(!e_cal_create_object(m_calendar, subcomp, &uid, &gerror) && gerror->domain == E_CALENDAR_ERROR && gerror->code == E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS) { e_cal_modify_object(m_calendar, subcomp, CALOBJ_MOD_ALL, &gerror) } This code no longer works because now e_cal_create_object() *removes* the conflicting UID. Then e_cal_modify_object() crashes because the hash is called with a NULL UID pointer. I don't know if this change was intentional; perhaps it was added to allow a second e_cal_create_object() too succeed. I think it would have been better to preserve the old behavior and document it. Clients need to decide how to handle the E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS error anyway and IMHO updating instead of duplicating the event is the more useful choice. If the client wanted to duplicate, it could clear the UID. Anyway, now that the reason is clear it was easy to add a workaround. Now the code makes less assumptions about e_cal_create_object() (which is always good) and restores the UID before e_cal_modify_object(). I'll keep the issue open until I have a SyncEvolution with the workaround released, then close it. Thanks to all who helped investigate this and to Matthew Barnes for pointing me in the right direction on the Evo developer list.
Just an update: the fix in SyncEvolution from current CVS seems to work here.
SyncEvolution 0.7 pre2 has been released and contains the fix. Can someone from the Evolution team please close this bug? I don't have the authorization for that. Thanks for your patience!
Closing.
*** Bug 485627 has been marked as a duplicate of this bug. ***
*** Bug 486834 has been marked as a duplicate of this bug. ***