[SyncEvolution] syncevolution-kde + akonadi [ERROR syncevo-dbus-server 00:00:00] child process quit because of signal 11
Patrick Ohly
patrick.ohly at intel.com
Mon May 30 10:01:52 UTC 2016
On Fri, 2016-05-27 at 10:13 +0300, Vladislav Vorobiev wrote:
> Hi,
>
> after some upgrades i run in the strage issue.
Signal 11 is a segfault. Sounds like something isn't compiled correctly
anymore or some component got broken. What is this upgrade that you ran?
Which OS? Which SyncEvolution binaries (i.e. from distro or
syncevolution.org)?
> $ SYNCEVOLUTION_DEBUG=3 syncevolution --sync two-way funambol calendar
> [DEBUG 00:00:00] SuspendFlags: (re)activating, currently inactive
> [DEBUG 00:00:00] SuspendFlags: activating signal handler(s) with fds 11->10
> [DEBUG 00:00:00] SuspendFlags: catch signal 2
> [DEBUG 00:00:00] SuspendFlags: catch signal 15
> [INFO 00:00:00] addressbook: inactive
> [INFO 00:00:00] memo: inactive
> [INFO 00:00:00] todo: inactive
> [INFO 00:00:00] calendar: starting normal sync, two-way (peer is server)
> [INFO 00:00:00] creating complete data backup of datastore calendar before
> sync (enabled with dumpData and needed for printChanges)
> [ERROR syncevo-dbus-server 00:00:00] child process quit because of signal 11
The actual failing process is the syncevo-dbus-helper, spawned by the
syncevo-dbus-server. To capture the actual segfault, running some item
operations directly under gdb with just one process involved will be the
easiest approach. Do it like this:
SYNCEVOLUTION_DEBUG=1 gdb --args syncevolution --daemon=no loglevel=10 --export /tmp/calendar.ics funambol calendar
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
More information about the SyncEvolution
mailing list