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

[deloptes]

Hi Patrick,
I am afraid I do not have your skills, but I am very thankful that you take
your time to investigate.
As mentioned before I always compile the old version from source (creating
debian packages for the desktop and rpm for the phone)
, then compiling the rest linked to the openobex library and it works like
it was working 10y ago.

Thank you once again for the effort.

regards

On Sat, Oct 3, 2020 at 5:09 PM Patrick Ohly <patrick.ohly at intel.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/syncevolution/attachments/20201003/077afb5c/attachment.htm>