[SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

[Patrick Ohly]

On Fri, 2017-09-29 at 22:22 +0200, deloptes wrote:
> I'm not sure I did all correctly
> 
> export LD_LIBRARY_PATH=/data-backup/DEVELOPMENT/Projects/tde-
> sup/sync_debug/openobex-1.7.2-Source/debian/build/lib

Looks like you are building libopenobex via the Debian packaging.
That's just unnecessarily complex and might have undesired effects like
stripping the lib during a build.

It's enough to checkout the source, apply my patch, then configure with
"CFLAGS=-g" and "make" (no need for "make install" or anything like
that).

Anyway, you can check with "list obex_hdr_it_equals" under gdb (after
loading the lib, for example after that segfault or after a "breakpoint
main") whether you have debug information in the lib, and whether the
listed source has my patch.

> SYNCEVOLUTION_DEBUG=10 ./src/syncevolution --daemon=no -r loglevel=6
> nokia_N9
> addressbook                                                          
>          
> 
> 
> DEBUG 00:00:02] ready to sync
> [DEBUG 00:00:02] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
> SyncEvolution session 1 server PC Suite
> [DEBUG 00:00:02] SAN datastore addressbook uri Contacts type 7 mode
> 206
> [DEVELOPER 00:00:02] ObexTransportAgent::wait(no reply)
> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
> ...
> [same removed]
> ...
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] Connecting Bluetooth device with address
> 40:98:4E:90:56:E3 and channel 25
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [DEVELOPER 00:00:04] OBEX Transport: get header who from connect
> response with value SYNCML-SYNC
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
> [INFO 00:00:04] Server sending SAN
> [DEVELOPER 00:00:04] ObexTransport send is called (46 bytes)
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(reply)
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): iteration
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [DEVELOPER 00:00:04] ObexTransport send completed
> [DEVELOPER 00:00:04] ObexTransportAgent::wait(): is ready
> [DEVELOPER 00:00:04] OBEX_EV_PROGRESS
> [DEVELOPER 00:00:04] OBEX_EV_REQDONE
> [ERROR 00:00:04] OBEX Request 3 got a failed response Unknown
> response

So that's still the same error. The question now is, where does this
"Unknown response" come from? What is the actual response code and
where was it set?

I'm afraid that will require a lot of digging in the libopenobex
sources. I don't have a clue what to look for, therefore I cannot
provide further guidance.

> [DEBUG 00:00:04] Server Alerted Sync init with SANFormat 12 failed,
> trying with legacy format
> [DEBUG 00:00:04] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce
> SyncEvolution session 1 server PC Suite
> [DEBUG 00:00:04] SAN datastore addressbook uri Contacts type text/x-
> vcard
> [DEBUG 00:00:04] SAN with overall sync mode 206
> [kcrash] TDECrash: Application 'SyncEvolution' crashing...
> Segmentation fault
> 
> In GDB
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff2614358 in smlLibMemcpy () from /usr/lib/x86_64-linux-
> gnu/libsmltk.so.0
> (gdb)   

Interesting :-/ Perhaps try running under valgrind to root-cause this
issue?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


_______________________________________________
SyncEvolution mailing list
SyncEvolution at syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution