On Mon, 2016-02-08 at 09:19 +0100, deloptes wrote: > Patrick Ohly wrote: > > > In case of a local sync, two processes are involved. You need to attach > > to syncevo-local-sync (gdb -p `pidof syncevo-local-sync`) and have a > > look where that one is stuck when the problem occurs. > > Thanks again for the hint. I do not have that much experience in debugging > at this level. > I'll check the details in the evening. If someone has time and idea to help > me further, here is the bt output (gdb -p `pidof syncevo-local-sync`). > > Loaded symbols for /usr/lib/libtqui.so.1 > 0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81 > 81 ../sysdeps/unix/syscall-template.S: No such file or directory. > (gdb) bt > #0 0x00007ffff5170e8d in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x00007ffff5ec4ee4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #2 0x00007ffff5ec4ffc in g_main_context_iteration () > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 > #3 0x00007ffff6b03891 in SyncEvo::LocalTransportAgentChild::step > (this=this@entry=0x67fd30, > status="waiting for parent's ACK for sync report") at > src/syncevo/LocalTransportAgent.cpp:818 > #4 0x00007ffff6b08bed in SyncEvo::LocalTransportAgentChild::run > (this=0x67fd30) at src/syncevo/LocalTransportAgent.cpp:1147 > #5 0x00007ffff6afd5b0 in SyncEvo::LocalTransportMain (argc=<optimized out>, > argv=<optimized out>) > at src/syncevo/LocalTransportAgent.cpp:1335 > #6 0x00007ffff50b2b45 in __libc_start_main (main=0x400940 > <SyncEvo::main(int, char**)>, argc=1, argv=0x7fffffffde98, > init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, > stack_end=0x7fffffffde88) at libc-start.c:287 > #7 0x000000000040099f in _start ()
So that really looks like an issue with the LocalTransport IPC mechanism. The "waiting for parent's ACK for sync report" explains what the target side of the local sync is waiting for. It's not clear why that fails. LocalTransportAgent::storeSyncReport() is the parent side and logs "got child sync report" once the data made it across the local D-Bus connection. Do you see that when running with SYNCEVOLUTION_DEBUG and loglevel=10? Another test might be to set up syncing between file backends. For that replace the TDE datastores on the target side of your sync config with another file backend, like you did on the local side. If that also fails, then it should be a problem that is completely independent of your TDE work. However, then you'd still have to debug it, as I haven't seen that myself so far :-/ -- 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
