[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[Patrick Ohly]

Patrick Ohly <patrick.ohly at intel.com> writes:

> Patrick Ohly <patrick.ohly at intel.com> writes:
>
>> deloptes <deloptes at gmail.com> writes:
>>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <patrick.ohly at intel.com> wrote:
>>>
>>>> Emanoil Kotsev <deloptes at yahoo.com> writes:
>>>> >  Hi,
>>>> > It is the file UPGRADING.txt in openobex not the README
>>>> > Upgrading to version 1.7Upgrading to version 1.6
>>>>
>>>> 1.7 is ancient (released 2016). I remember reading about "When using an
>>>> event loop that triggers on incoming data, you must call
>>>> OBEX_HandleInput() after each call to OBEX_Request() to actually send
>>>> the request"
>>>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt).
>>>> If I remember correctly, my conclusion was that SyncEvolution does that,
>>>> but I am not sure anymore.
>>>>
>>>>
>>> I am also not sure where and how this has to be done. I think I have looked
>>> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(),
>>> but I am not quite sure at all. It could be also something completely
>>> different.
>>
>> Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is
>> really missing. I don't know exactly whether it now gets called only
>> when the fd is ready.
>
> I wanted to try that out, but it turns out that all of my SyncML-capable
> phones are dead, i.e. I can no longer test the SyncML over OBEX code. I
> already bought a cheap used one via eBay, but that also was dead. I'll
> try with another one...

I now have a phone again and can reproduce the issue.

But some additional debug output shows that OBEX_HandleInput is called
after OBEX_Request:

[DEVELOPER 00:00:02] OBEX Transport: get header who from connect response with value SYNCML-SYNC
[DEVELOPER 00:00:02] ObexTransportAgent::wait(): is ready
[ERROR 00:00:02] GLib: Source ID 2 was not found when attempting to remove it
[INFO 00:00:02] Server sending SAN
[DEVELOPER 00:00:02] ObexTransport send is called (116 bytes)
[DEVELOPER 00:00:02] ObexTransportAgent: OBEX_Request for OBEX_CMD_PUT
[DEVELOPER 00:00:02] ObexTransportAgent::wait(reply)
[DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput
[DEVELOPER 00:00:02] OBEX_EV_PROGRESS
[DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput
^C
[DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration
[DEBUG 00:00:05] SuspendFlags: read 7 from fd 5
[DEBUG 00:00:05] reveived signal 2
[DEBUG 00:00:05] CancelTransport: cancelling because of SuspendFlags::ABORT
[DEVELOPER 00:00:05] ObexTransportAgent::shutdown()
[DEVELOPER 00:00:05] ObexTransportAgent::wait(no reply)
[DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration
[DEVELOPER 00:00:05] ObexTransportAgent: OBEX_HandleInput
*** buffer overflow detected ***: install_new_openobex/bin/syncevolution terminated

The buffer overflow is happening inside the new libopenobex after
SyncEvolution called OBEX_CancelRequest and while SyncEvolution is
waiting for the pending command to finish. This does not happen with the
old libopenobex.

That aside, the key point is that it's not getting stuck because of the
issue mentioned in the openobex 1.7 release notes. Wireshark also shows
that some data goes out. Unfortunately it stop decoding data at the
RFCOMM level, so it's not immediately obvious what's going on for OBEX.

The next step was to try with an older libopenobex. I force-installed an
old libopenobex1-dev and libopenobex; that didn't install cleanly, but
the files seemed to be in place and it was possible to link against
them. However, the resulting binary then got stuck the same way (but
allowed to abort cleanly).

I also tried running the last stable release inside Docker:


docker run --rm -ti --net=host --privileged --volume \
  /home/pohly/.config:/config \
  --volume \
  /tmp/syncevolution-bundle_1.5.3-2_amd64.deb:/tmp/syncevolution-bundle_1.5.3-2_amd64.deb \
  --volume /dev:/dev --volume /sys:/sys debian:stretch

And inside it:

  apt-get update && apt-get install /tmp/syncevolution-bundle_1.5.3-2_amd64.deb -f
  XDG_CONFIG_HOME=/config SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync refresh-from-remote --sync-property loglevel=10 NokiaPhone

But that segfaults while preparing the SAN, i.e. even earlier.

==2063== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==2063==  Bad permissions for mapped region at address 0x7F0E358
==2063==    at 0x7F0E358: ??? (in /usr/lib/libsmltk.so.0.6.0)
==2063==    by 0x56A87B5: sysync::newPCDataStringX(unsigned char const*, bool, int) (sysync_utils.cpp:2992)
==2063==    by 0x56A64AD: sysync::SanPackage::GetPackageLegacy(void*&, unsigned long&, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, int, bool) (san.cpp:757)
==2063==    by 0x56224C6: SyncEvo::SyncContext::sendSAN(unsigned short) (SyncContext.cpp:3642)
==2063==    by 0x562A6A2: SyncEvo::SyncContext::doSync() (SyncContext.cpp:3829)
==2063==    by 0x5631338: SyncEvo::SyncContext::sync(SyncEvo::SyncReport*) (SyncContext.cpp:3446)
==2063==    by 0x55AB3D6: SyncEvo::Cmdline::run() (Cmdline.cpp:1726)
==2063==    by 0x416823: main (syncevolution.cpp:533)

I've never used this particular config before; it's possible that I
screwed it up when preparing for syncing with the new phone. But that
shouldn't lead to a segfault.

I'll have to try next with the old release compiled from source to debug
that.

-- 
Best Regards

Patrick Ohly
_______________________________________________
SyncEvolution mailing list -- syncevolution at syncevolution.org
To unsubscribe send an email to syncevolution-leave at syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s