Michael Bell wrote:
> Henrik /KaarPoSoft schrieb:
>> Running fresh out of SVN (r288).
>> msynctool with a syncml-obex-client gives segmentation fault.
>> trace from valgrind:
>> ==20460== Invalid read of size 4
>> ==20460== at 0x4B41526: smlDevInfAgentRegisterSession
>> ==20460== by 0x4B4198C: smlDevInfAgentRegister (sml_devinf_obj.c:402)
>> ==20460== by 0x46C5F1C: syncml_obex_client_init
>> ==20460== by 0x4079EEF: osync_plugin_initialize
>> ==20460== by 0x404D8F0: _osync_client_handle_initialize
>> ==20460== by 0x404F1EB: _osync_client_message_handler
>> ==20460== by 0x406F3CF: _incoming_dispatch (opensync_queue.c:101)
>> ==20460== by 0x40B9610: g_main_context_dispatch (in
>> ==20460== by 0x40BCA95: (within /usr/lib/libglib-2.0.so.0.1400.0)
>> ==20460== by 0x40BCE03: g_main_loop_run (in
>> ==20460== by 0x40DD1A3: (within /usr/lib/libglib-2.0.so.0.1400.0)
>> ==20460== by 0x445B561: start_thread (in /lib/i686/libpthread-2.4.so)
>> It seems to me that the problem comes from
>> In line 402 we call
>> SmlBool retval = smlDevInfAgentRegisterSession(agent, manager, NULL,
>> In line 312 we find smlDevInfAgentRegisterSession:
>> SmlBool smlDevInfAgentRegisterSession(SmlDevInfAgent *agent,
>> SmlManager *manager, SmlSession *session, SmlError **error)
>> So, we call smlDevInfAgentRegisterSession with session=NULL
>> But in line 325 we have:
>> if (session->sessionType == SML_SESSION_TYPE_CLIENT)
>> which fails because session=NULL
> Thanks for the cool analysis. If fixed it in rev291. The problem is
> that we have to know in which SyncML mode we operate (client or
> server). I introduced now a new function in the manager which makes
> the decision on base of the transport type.
> Nevertheless I have now a new SegFault :( If I run --discover then it
> crashs after the plugin function returns and before the available
> types and formats are displayed.
> Best regards
Thank you very much for the correction!!
I do *not* get a segfault in --discover; it seems to work.
However, when I do a first slow-sync, syncml-obex-client reports no changes.
I have not yes figured out why, but there is one strange thing:
I get a logfile with just those two lines in it:
[1196190250.417415] >>>>>>> _ds_alert(0x808a238, 0x8078b70)
[1196190250.417559] <<<<<<< _ds_alert