Patrick Ohly wrote: > 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. >
I am not building the whole package, but notice taken, I now build the classic way. > 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. > Yes, I will double check all details and will try to get more useful information >> [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? > I did - there are 2 pointer errors from the tdepim plugins. I will try to fix them and will come back again when I have something useful. It works great with obex 1.5. So it is not urgent but anyway it is not a really usable for the public. thanks regards _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
