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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Yes it does, at line 360, in get_changeinfo().

	Danny

On Thu, 2005-08-18 at 18:10 +0200, Armin Bauer wrote:
> Hi,
>=20
> Thats very weird.
>=20
> According to the assert it stoped here:
>=20
> ** ERROR **: file opensync_hashtable.c: line 225
> (osync_hashtable_update_hash): should not be reached
> aborting...
>=20
> 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.
>=20
> can you check if your plugin calls osync_hashtable_update_hash or
> osync_hashtable_report_deleted at some point?
>=20
> Armin
>=20
> Danny Backx wrote:
> > On Wed, 2005-08-17 at 11:09 +0200, Armin Bauer wrote:
> >=20
> >>>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 =3D 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 =3D 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.
> >=20
> >=20
> > Ok, I've downloaded and compiled from the repository now.
> >=20
> >=20
> >>>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?
> >=20
> >=20
> > 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 :-)
> >=20
> > 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).
> >=20
> > 	Danny
> >=20
> >=20
> >>>   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 previou=
s
> >>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.=20
> >>>>If someone is interested please watch my blog and give a try to it:
> >>>>http://www.mirkuz.net/?cat=3D9
--=20
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info