discover + sync = crash

[Chris Frey-2]

Hi,

If I apply the following patch to osynctool:

--- a/tools/osynctool.c
+++ b/tools/osynctool.c
@@ -1652,6 +1652,7 @@ int main (int argc, char *argv[])
                                goto error_free_group_env;
                        break;
                case OSYNCTOOL_SYNC:
+                       osynctool_configure_discover(group_env, plugin_env, groupname, membername, &error);
                        if (!osynctool_synchronize(group_env, groupname, wait, multi, slow_objects, &error)) {
                                g_list_free(slow_objects);
                                goto error_free_plugin_env;


Then when I run --sync (which now does the discover first), the sync
will give a segmentation fault.

I'm trying to figure out why this is the case, but if anyone has any
tips, I'm all ears.  I need this sort of behaviour so that it is safe
to do all the config, discover, and sync, from one instance of a program,
and not have to start fresh each time like osynctool.

Thanks,
- Chris




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Ian Martin-3]

2009/10/22 Chris Frey <cdfrey@...>:
> Here are the backtraces of all threads:  (crashed thread is at the end)

> (gdb) thread 31
> [Switching to thread 31 (Thread 0xb25ffb90 (LWP 25739))]#0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> (gdb) bt
> #0  0xb7bb98f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
> #1  0xb7ecea9d in pthread_cond_wait () from /lib/libc.so.6
> #2  0xb7754c24 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
> #3  0xb7759618 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
> #4  0xb7759825 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
> #5  0xb7765fc2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
> #6  0xb767e65f in GNOME_Evolution_Calendar_CalFactory_getCal (_obj=0xb3600a50,
>    source=0xb3600b30 "<?xml version=\"1.0\"?>\n<source uid=\"1256244172.25695.5@frontdesk\" name=\"\" uri=\"file:///home/tarball/.evolution/calendar/local/system\"/>\n", type=1, listener=0x848e6b0, ev=0xb25ff038)
>    at Evolution-DataServer-Calendar-stubs.c:426
> #7  0xb7682022 in e_cal_new (source=0x834c420, type=E_CAL_SOURCE_TYPE_EVENT)
>    at e-cal.c:1296
> #8  0xb7682330 in e_cal_new_from_uri (
>    uri=0x8482f68 "file:///home/tarball/.evolution/calendar/local/system",
>    type=E_CAL_SOURCE_TYPE_EVENT) at e-cal.c:1449
> #9  0xb76824dd in e_cal_new_system_calendar () at e-cal.c:1478
> #10 0xb768b36d in e_cal_open_default (ecal=0xb25ff10c,
>    type=E_CAL_SOURCE_TYPE_EVENT, func=0, data=0x0, error=0xb25ff108)
>    at e-cal.c:5135
> #11 0xb79c73bb in evo2_ecal_open_cal (path=0x84796e0 "default",
>    source_type=E_CAL_SOURCE_TYPE_EVENT, error=0xb25ff144)
>    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:67
> #12 0xb79c7509 in evo2_ecal_connect (sink=0x83f3648, info=0x83fd338,
>    ctx=0x8482d30, userdata=0x83b6890)
>    at /home/cdfrey/software/opensync/git/plugins/evolution2/src/evolution2_ecal.c:91
> #13 0xb806ca1f in osync_objtype_sink_connect (sink=0x83f3648, info=0x83fd338,
>    ctx=0x8482d30)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/plugin/opensync_objtype_sink.c:327
> #14 0xb80235cb in _osync_client_handle_connect (client=0x8354148,
>    message=0x84796b8, error=0xb25ff224)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1050
> #15 0xb80248cf in _osync_client_message_handler (message=0x84796b8,
>    user_data=0x8354148)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/client/opensync_client.c:1514
> #16 0xb8057c3d in _incoming_dispatch (source=0x8354960, callback=0,
>    user_data=0x8353fc8)
>    at /home/cdfrey/software/opensync/git/opensync/opensync/ipc/opensync_queue.c:391
> #17 0xb7f701d8 in IA__g_main_context_dispatch (context=0x8354db8)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2012
> #18 0xb7f73873 in g_main_context_iterate (context=0x8354db8, block=1,
>    dispatch=1, self=0x83580c0)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2645
> #19 0xb7f73d92 in IA__g_main_loop_run (loop=0x8357bf0)
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gmain.c:2853
> #20 0xb7f9a16f in g_thread_create_proxy (data=0x83580c0)
> ---Type <return> to continue, or q <return> to quit---
>    at /build/buildd-glib2.0_2.16.6-2-i386-PgybGk/glib2.0-2.16.6/glib/gthread.c:635
> #21 0xb7bb5f3b in start_thread () from /lib/libpthread.so.0
> #22 0xb7ec2bee in clone () from /lib/libc.so.6
>

It seems the calls to e_cal_open_default triggers the crash on the
second creation of an osync_engine

Setting the evo2sync plugin to run as a process not a thread fixes the
segfault.  I'm not sure what is causing this though - something to do
with the loading /unloading of evo2sync on engine creation destruction

Patch attached for you to try

Running as a process seems to cause some problems with queue timeouts.

Ian

[start_as_process.diff]

---

diff --git a/src/evolution2_sync.c b/src/evolution2_sync.c
index 853bf0d..e66a810 100644
--- a/src/evolution2_sync.c
+++ b/src/evolution2_sync.c
@@ -220,6 +220,7 @@ osync_bool get_sync_info(OSyncPluginEnv *env, OSyncError **error)
  osync_plugin_set_initialize(plugin, evo2_initialize);
  osync_plugin_set_finalize(plugin, evo2_finalize);
  osync_plugin_set_discover(plugin, evo2_discover);
+ osync_plugin_set_start_type(plugin, OSYNC_START_TYPE_PROCESS);
 
  if (!osync_plugin_env_register_plugin(env, plugin, error))
  goto error;

---

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel