Description of problem: I'm currently unable to sync tasks w/ our Exchange server. Both calendar appointments and mail components sync. Upon trying to create a new task in evolution (under the Exchange account), I get the following error: No such interface `org.gnome.evolution.dataserver.Calendar' on object at path /org/gnome/evolution/dataserver/Calendar/4985/5 Version-Release number of selected component (if applicable): evolution-ews-3.6.3-1.fc18.x86_64 Additional info: Tasks sync and creation was working under evolution-mapi under Fedora 17. I upgraded to Fedora 18 around the time that we upgraded our Exchange server from 2007 to 2010 (requiring the mapi -> ews plugin switch). I don't use Evolution every day, so I'm not sure exactly when the breakage happened. I've got two Fedora 18 workstations, and am having the same issue on both. I'm using KDE as my desktop.
To be clear, both calendar appointments and mail components sync fine. The issue is only with Tasks. Toggling the Exchange account checkbox on the left pane of "Tasks" doesn't seem to help.
(In reply to comment #0) > No such interface `org.gnome.evolution.dataserver.Calendar' on object at > path /org/gnome/evolution/dataserver/Calendar/4985/5 Thanks for a bug report. The above error can mean that the evolution-calendar-factory process crashed. Do you have any ABRT reports for that process pending on your machine?
I tried to reproduce this on my machine and it works fine, I can create tasks, same as they are shown from my Exchange 2010 server.
(In reply to comment #2) > (In reply to comment #0) > > No such interface `org.gnome.evolution.dataserver.Calendar' on object at > > path /org/gnome/evolution/dataserver/Calendar/4985/5 > > Thanks for a bug report. The above error can mean that the > evolution-calendar-factory process crashed. Do you have any ABRT reports for > that process pending on your machine? Milan, No ABRT recorded crashes. But I do notice that evolution-calendar-factory keeps stopping all by itself. Perhaps this is related to bug #908477?, as doing something like toggling the account check box (on tasks or calendars) will restart it.
It can stop on its own when there are no clients connected to it, which is an ideal situation when you run evolution in the calendar, check some events and then close evolution again. If it closes itself in the middle of a work in evolution calendar, then there can be something wrong. I would try to run the factory on a console, to see what it does. You can do that like this: a) close evolution and evolution-alarm-notify processes b) open a terminal and run there: $ /usr/libexec/evolution-calendar-factory -w &>log.txt c) run evolution like before, and basically do everything like you use to, only occasionally check whether the factory on console is still running. When it'll stop, check the log.txt file content, and maybe upload it here - it should not contain any private data.
I made sure no evolution related processes were running, then went ahead and started calendar factory. In another terminal I'm watching it with "watch ps -C evolution-calendar-factory". In a second terminal I'm watching the log file with "tail -f". Everything that is written to the log file, is written at this point. That is this: Registering ECalBackendMapiTodosFactory ('mapi:VTODO') Registering ECalBackendFileEventsFactory ('local:VEVENT') Registering ECalBackendFileJournalFactory ('local:VJOURNAL') Registering ECalBackendFileTodosFactory ('local:VTODO') Registering ECalBackendHttpEventsFactory ('webcal:VEVENT') Registering ECalBackendHttpJournalFactory ('webcal:VJOURNAL') Registering ECalBackendHttpTodosFactory ('webcal:VTODO') Registering ECalBackendContactsEventsFactory ('contacts:VEVENT') Server is up and running... Bus name 'org.gnome.evolution.dataserver.Calendar3' acquired. At this point I start evolution, and then notice that in the terminal that we launched evolution-calendar-factory from, that there is a segfault: $ /usr/libexec/evolution-calendar-factory -w &>log.txt Segmentation fault I repeated this about three times in a row, and as soon as I launch evolution, evolution-calendar-factory segfaults. Why ABRT isn't picking it up, I don't know. I checked "systemctl status abrtd.service", and ABRT is active (running).
Additionally, sometimes when starting evolution-calendar-factory it seems to register more Factories. For instance the log from the first two times I started it, were identical to the above (Comment #6). However the log from the 3rd time was this: Registering ECalBackendCalDAVEventsFactory ('caldav:VEVENT') Registering ECalBackendCalDAVJournalFactory ('caldav:VJOURNAL') Registering ECalBackendCalDAVTodosFactory ('caldav:VTODO') Registering ECalBackendWeatherEventsFactory ('weather:VEVENT') Registering ECalBackendEwsEventsFactory ('ews:VEVENT') Registering ECalBackendEwsJournalFactory ('ews:VJOURNAL') Registering ECalBackendEwsTodosFactory ('ews:VTODO') Registering ECalBackendMapiEventsFactory ('mapi:VEVENT') Registering ECalBackendMapiJournalFactory ('mapi:VJOURNAL') Registering ECalBackendMapiTodosFactory ('mapi:VTODO') Registering ECalBackendFileEventsFactory ('local:VEVENT') Registering ECalBackendFileJournalFactory ('local:VJOURNAL') Registering ECalBackendFileTodosFactory ('local:VTODO') Registering ECalBackendHttpEventsFactory ('webcal:VEVENT') Registering ECalBackendHttpJournalFactory ('webcal:VJOURNAL') Registering ECalBackendHttpTodosFactory ('webcal:VTODO') Registering ECalBackendContactsEventsFactory ('contacts:VEVENT') Server is up and running... Bus name 'org.gnome.evolution.dataserver.Calendar3' acquired. Don't know if that relevant or not.
And I've just noticed that my logs are littered with messages like this: [ 3582.366748] pool[10461]: segfault at 6 ip 00007f0bff775870 sp 00007f0bc9ffab70 error 4 in libeews-1.2.so.0.0.0[7f0bff750000+3f000]
Thanks for the update. I guess the comment #3 shows only the tail of the log, while the comment #4 shows it full, right? Anyway, could you run the factory under gdb, to get the backtrace please? Make sure you've installed debuginfo packages for evolution-ews (there the crash happens) and evolution-data-server and then run the factory like before, only instead of logging into a file do this: $ gdb /usr/libexec/evolution-calendar-factory --ex "r w" --ex "t a a bt" --ex q then run evolution and switch to this factory console and gather whole backtrace (of all threads) by pressing "enter" and finally confirm the quit. Please check the backtrace for private information, as it can crash during authentication. I usually search for "pass" in the log (quotes for clarity only). Also, could you paste here result of this, please? $ rpm -qa | grep evolution | sort
(In reply to comment #9) > Thanks for the update. I guess the comment #3 shows only the tail of the > log, while the comment #4 shows it full, right? I assume you mean comment #6 and comment #7? If so, no. Both are full logs. I was noting that sometimes it seems to register more factories on startup than other times. > Also, could you paste here result of this, please? > $ rpm -qa | grep evolution | sort $ rpm -qa | grep evolution | sort evolution-3.6.3-2.fc18.x86_64 evolution-data-server-3.6.3-1.fc18.x86_64 evolution-data-server-debuginfo-3.6.3-1.fc18.x86_64 evolution-debuginfo-3.6.3-2.fc18.x86_64 evolution-ews-3.6.3-1.fc18.x86_64 evolution-ews-debuginfo-3.6.3-1.fc18.x86_64 evolution-help-3.6.3-2.fc18.noarch evolution-mapi-3.6.3-1.fc18.x86_64
I ran gdb as you mentioned in comment #9. I was noticing the options being passed to evolution-calendar-factory, and it seemed as if it needed to be launched as follows: gdb /usr/libexec/evolution-calendar-factory --ex "r -w" --ex "t a a bt" --ex q namely, the '-', had to be put before the 'w'., so that it didn't exit immediately. (I noticed that 'w', and not '-w' was being passed to evolution-calendar-factory without it.)
Created attachment 697977 [details] evolution-ews backtrace
Oops, you are right, I mean the other comments. I'm sorry for that, same as for the "w" versus "-w". I see from the backtrace what's going on, it's fixed within bug #904236, thus I'm closing this as a duplicate of it. I'll build an evolution-ews update with the upstream fix included and update the other bug. *** This bug has been marked as a duplicate of bug 904236 ***