Re: [Opensync-users] Hi there [synce-plugin]

[Armin B. <arm...@de...>]

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