Menu
▾
▴
[Opensync-users] msynctool hangs after successful sync (was: Re: opensync+isync breaks fast syncing, generates dupes)
|
From: Simon J. <si...@jo...> - 2008-02-21 14:53:16
|
Michael Bell <mic...@cm...> writes: > Michael Bell schrieb: > >> The problem is that the plugin signals SLOW-SYNC during connect but >> OpenSync or msynctool does not react. I don't know which part of the >> software should check for such an event. Perhaps Daniel can clarify >> this. If I know where I have to search then I can try to find the >> bug. >> >> So your problem is still some kind of open. We fixed the first bug >> and found another one :( > > The SLOW-SYNC is signalled now correctly. I described the bug a little > bit more in detail on opensync-devel. The SLOW-SYNC issue is fixed > with SVN version 3184 of opensync. More details can be found in the > mail archive of the devel list. > > http://sourceforge.net/mailarchive/forum.php?thread_name=47BD87CE.2000501%40cms.hu-berlin.de&forum_name=opensync-devel > > If someone (especially Simon ;) ) could verify the change then this > would be really nice. Thanks! I'm trying to test it, but I'm running into a separate problem: Running msynctool appears to works fine, but it doesn't seem to shut down properly. So it will always flag the sync as unclean, and the next sync will be a slow-sync. (That's why I can't test your patch: all my sync are slow-syncs!) A gdb backtrace is rather useless, see below. The trace logs doesn't grow when opensync is in this state. The tail of the first thread log is: [1203605481.656762] <<<<<<< smlTransportReceiveEvent: 1 [1203605481.656799] <<<<<<< smlTransportObexClientDisconnect [1203605481.656836] <<<<<<< smlTransportWorkerHandler [1203605481.656876] >>>>>>> smlTransportWorkerHandler(0xb0f1ded8, 0x807c480) [1203605481.656915] >>>>>>> smlTransportObexClientDisconnect(0x8079048, (nil)) [1203605481.656963] Disconnect loop 0 The tail of the second thread log file is: [1203605481.657388] <<<<<<< smlDsSessionDispatch() [1203605481.657424] >>>>>>> smlDsSessionDispatch(0x809b998) [1203605481.657458] recvChanges: (nil) changesCallback: 0xb7192fe0 [1203605481.657491] <<<<<<< smlDsSessionDispatch() [1203605481.657525] >>>>>>> smlManagerDispatch(0x807c278) [1203605481.657592] >>>>>>> _smlManagerEventFree(0x808dcc8) [1203605481.657628] <<<<<<< _smlManagerEventFree [1203605481.657663] <<<<<<< smlManagerDispatch [1203605481.679998] >>>>>>> smlManagerStop(0x807c278) [1203605481.680384] >>>>>>> smlThreadStop(0x8078170) Any ideas on how to track this down? I may be building opensync without debug symbols, which would explain the useless gdb stacktrace. I don't know cmake well, how do I turn off optimization and on debugging? /Simon (gdb) r --sync e51-file Starting program: /home/jas/bin/msynctool --sync e51-file [Thread debugging using libthread_db enabled] [New Thread 0xb7a366b0 (LWP 21424)] Synchronizing group "e51-file" [New Thread 0xb7053b90 (LWP 21427)] [Thread 0xb7053b90 (LWP 21427) exited] [New Thread 0xb6852b90 (LWP 21428)] [Thread 0xb6852b90 (LWP 21428) exited] The previous synchronization was unclean. Slow-syncing [New Thread 0xb6852b90 (LWP 21429)] [New Thread 0xb7053b90 (LWP 21430)] [New Thread 0xb6051b90 (LWP 21431)] [New Thread 0xb5850b90 (LWP 21432)] [New Thread 0xb504fb90 (LWP 21433)] [New Thread 0xb484eb90 (LWP 21434)] [New Thread 0xb404db90 (LWP 21435)] [New Thread 0xb384cb90 (LWP 21436)] [New Thread 0xb304bb90 (LWP 21437)] [New Thread 0xb284ab90 (LWP 21438)] [New Thread 0xb2049b90 (LWP 21439)] [New Thread 0xb1848b90 (LWP 21440)] event sink of member 1 of type file-sync just connected contact sink of member 1 of type file-sync just connected Main sink of member 1 of type file-sync just connected Main sink of member 2 of type syncml-obex-client just connected ... Received an entry 1126 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 1127 from member 2 (syncml-obex-client). Changetype ADDED Received an entry 1128 from member 2 (syncml-obex-client). Changetype ADDED contact sink of member 2 of type syncml-obex-client just sent all changes All clients sent changes or error All conflicts have been reported Received an reply to our sync Received an reply to our sync Main sink of member 2 of type syncml-obex-client committed all changes. event sink of member 1 of type file-sync committed all changes. contact sink of member 1 of type file-sync committed all changes. Main sink of member 1 of type file-sync committed all changes. contact sink of member 2 of type syncml-obex-client committed all changes. event sink of member 2 of type syncml-obex-client committed all changes. All clients have written event sink of member 2 of type syncml-obex-client reported sync done. contact sink of member 2 of type syncml-obex-client reported sync done. Main sink of member 2 of type syncml-obex-client reported sync done. event sink of member 1 of type file-sync reported sync done. contact sink of member 1 of type file-sync reported sync done. Main sink of member 1 of type file-sync reported sync done. All clients reported sync done The sync was successful event sink of member 1 of type file-sync just disconnected contact sink of member 1 of type file-sync just disconnected Main sink of member 1 of type file-sync just disconnected event sink of member 2 of type syncml-obex-client just disconnected contact sink of member 2 of type syncml-obex-client just disconnected Main sink of member 2 of type syncml-obex-client just disconnected All clients have disconnected [Thread 0xb504fb90 (LWP 21433) exited] Program received signal SIGINT, Interrupt. [Switching to Thread 0xb7a366b0 (LWP 21424)] 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7ae8aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7dc97bd in pthread_cond_wait () from /lib/i686/cmov/libc.so.6 #3 0xb7e5b002 in ?? () from /usr/lib/libglib-2.0.so.0 #4 0x0806f0a0 in ?? () #5 0x0806b018 in ?? () #6 0xb7f5ca10 in ?? () #7 0xb7e2eff4 in ?? () from /lib/i686/cmov/libc.so.6 #8 0x0806b000 in ?? () #9 0xb7ee99c0 in ?? () from /usr/lib/libglib-2.0.so.0 #10 0x00000000 in ?? () (gdb) |
