From: Armin B. <arm...@de...> - 2005-08-19 16:12:26
|
Here in my version it is commented out (with the /* */ comments). Is it also commented in yours? Armin Danny Backx wrote: > Yes it does, at line 360, in get_changeinfo(). > > Danny > > On Thu, 2005-08-18 at 18:10 +0200, Armin Bauer wrote: > >>Hi, >> >>Thats very weird. >> >>According to the assert it stoped here: >> >>** ERROR **: file opensync_hashtable.c: line 225 >>(osync_hashtable_update_hash): should not be reached >>aborting... >> >>The weird thing is: this function never could get called from the synce >>plugin (all occurences are commented out) which leads me to the >>conclusion that either you are using a different version of the synce >>plugin than i use or the stack got corrupted in a very bad way. >> >>can you check if your plugin calls osync_hashtable_update_hash or >>osync_hashtable_report_deleted at some point? >> >>Armin >> >>Danny Backx wrote: >> >>>On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote: >>> >>> >>>>>2. After that, msynctool --listplugins didn't pick up the new library. >>>>> Setting OSYNC_TRACE made me discover that the symbol >>>>> osync_plugin_new_info() >>>>> was used by the plugin, but not defined by my installation of >>>>> opensync. Looking through the material on opensync.org makes me >>>>> conclude that the synce-plugin, and some of the material on >>>>> opensync.org, are referring to a newer version of the API than >>>>> what I have. >>>>> So I edited the get_info call to start with this : >>>>> void get_info(OSyncPluginInfo *info) >>>>> { >>>>> instead of >>>>> void get_info(OSyncPluginInfo *env) >>>>> { >>>>> OSyncPluginInfo *info = osync_plugin_new_info((void*)env); >>>>> >>>>> Can someone comment on these API versions ? >>>>> >>>> >>>>i changed the API from this: >>>> >>>>get_info(OSyncPluginInfo *info) >>>> >>>>to this: >>>> >>>>get_info(OSyncPluginInfo *env) >>>>{ >>>> OSyncPluginInfo *info = osync_plugin_new_info((void*)env); >>>> >>>>some time ago to allow one module to register several plugins at once >>>>(this is for example used in the syncml plugin). So you have to update >>>>your opensync installation. If you would like to beta test plugins i >>>>_strongly_ suggest that you use code directly from the repository so i >>>>can deliver you fixes for bugs that will show up more easy. >>> >>> >>>Ok, I've downloaded and compiled from the repository now. >>> >>> >>> >>>>>3. I could then set up everything with msynctool. I added a pair to >>>>> synchronize between synce and the file-sync plugin. >>>>> >>>> >>>>that trace shows that it aborted with g_assert_warning () so there >>>>should be an assert message on stdour or stderr. can you show this >>>>warning to me? >>> >>> >>>There were too many messages for the xterm log so it got lost. I'm >>>trying to reproduce now but I managed to clear my contacts by clearing >>>the directory :-) >>> >>>I'll send a log of my attempts to upload it to Armin and Mirko, maybe >>>it's of help to them. They show similar interaction to what I >>>encountered the other day, but with another scenario (and now with >>>the right software version). >>> >>> Danny >>> >>> >>> >>>>> The first attempt to synchronize did some work (and left a lot of >>>>> files in the file-sync directory), but then msynctool crashed. Gdb >>>>> shows the following stack trace : >>>>>#0 0xffffe410 in ?? () >>>>>#1 0xb73e8c48 in ?? () >>>>>#2 0x00000006 in ?? () >>>>>#3 0x00002503 in ?? () >>>>>#4 0xb7b926e5 in raise () from /lib/tls/libc.so.6 >>>>>#5 0xb7b94049 in abort () from /lib/tls/libc.so.6 >>>>>#6 0xb7e4ad0d in g_logv () from /usr/local/lib/libglib-2.0.so.0 >>>>>#7 0xb7e4ad9d in g_log () from /usr/local/lib/libglib-2.0.so.0 >>>>>#8 0xb7e4ae44 in g_assert_warning () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#9 0xb7ee8211 in osync_hashtable_update_hash () >>>> >>>>>from /usr/local/lib/libopensync.so.0 >>>> >>>>>#10 0xb756233b in fs_commit_change () >>>> >>>>>from /usr/local/lib/opensync/plugins/file_sync.so >>>> >>>>>#11 0xb7ee684a in osync_member_commit_change () >>>> >>>>>from /usr/local/lib/libopensync.so.0 >>>> >>>>>#12 0xb7ef8910 in client_message_handler () >>>> >>>>>from /usr/local/lib/libosengine.so.0 >>>> >>>>>#13 0xb7ef8363 in _queue_dispatch () >>>> >>>>>from /usr/local/lib/libosengine.so.0 >>>> >>>>>#14 0xb7e430c4 in g_main_dispatch () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#15 0xb7e43f1d in g_main_context_dispatch () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#16 0xb7e442df in g_main_context_iterate () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#17 0xb7e448a3 in g_main_loop_run () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#18 0xb7e5cbea in g_thread_create_proxy () >>>> >>>>>from /usr/local/lib/libglib-2.0.so.0 >>>> >>>>>#19 0xb7cd03b0 in start_thread () from /lib/tls/libpthread.so.0 >>>>>#20 0xb7c3226e in clone () from /lib/tls/libc.so.6 >>>>> >>>>> A second attempt to synchronize required me to answer a lot of >>>>> questions to solve synchronisation problems, but eventually the >>>>> synchronisation succeeded. >>>>> >>>> >>>>This means that the format comparison is not yet completely correct for >>>>this synchronization. Since your synchronization crashed on the previous >>>>sync, opensync automatically initiated a slow-sync which means that it >>>>compares every entry from the devices again. >>>> >>>>If the comparison is not done 100% correct, it sometimes raises >>>>conflicts when it should not have. Please take a look at this quide >>>>which show how to enable tracing: http://www.opensync.org/wiki/tracing >>>> >>>>After you have traced the synchronization which results in the >>>>conflicts, please send me the trace files so i can fix this problem. >>>> >>>> >>>> >>>>> Danny >>>>> >>>>>On Thu, 2005-08-11 at 16:27 +0200, mirko wrote: >>>>> >>>>> >>>>> >>>>>>Hi, i'm trying to develop a synce-plugin for opensync. >>>>>>I just made my first release.. 0.01. it should work with addressbook but >>>>>>it's still buggy. >>>>>>If someone is interested please watch my blog and give a try to it: >>>>>>http://www.mirkuz.net/?cat=9 |