<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div>Hi Patrick,</div><div>I am afraid I do not have your skills, but I am very thankful that you take your time to investigate.</div><div>As mentioned before I always compile the old version from source (creating debian packages for the desktop and rpm for the phone)<br></div><div>, then compiling the rest linked to the openobex library and it works like it was working 10y ago.</div><div><br></div><div>Thank you once again for the effort.</div><div><br></div><div>regards<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 3, 2020 at 5:09 PM Patrick Ohly <<a href="mailto:patrick.ohly@intel.com">patrick.ohly@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Patrick Ohly <<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>> writes:<br> <br> > Patrick Ohly <<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>> writes:<br> ><br> >> deloptes <<a href="mailto:deloptes@gmail.com" target="_blank">deloptes@gmail.com</a>> writes:<br> >>> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>> wrote:<br> >>><br> >>>> Emanoil Kotsev <<a href="mailto:deloptes@yahoo.com" target="_blank">deloptes@yahoo.com</a>> writes:<br> >>>> > Hi,<br> >>>> > It is the file UPGRADING.txt in openobex not the README<br> >>>> > Upgrading to version 1.7Upgrading to version 1.6<br> >>>><br> >>>> 1.7 is ancient (released 2016). I remember reading about "When using an<br> >>>> event loop that triggers on incoming data, you must call<br> >>>> OBEX_HandleInput() after each call to OBEX_Request() to actually send<br> >>>> the request"<br> >>>> (<a href="https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt" rel="noreferrer" target="_blank">https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt</a>).<br> >>>> If I remember correctly, my conclusion was that SyncEvolution does that,<br> >>>> but I am not sure anymore.<br> >>>><br> >>>><br> >>> I am also not sure where and how this has to be done. I think I have looked<br> >>> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(),<br> >>> but I am not quite sure at all. It could be also something completely<br> >>> different.<br> >><br> >> Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is<br> >> really missing. I don't know exactly whether it now gets called only<br> >> when the fd is ready.<br> ><br> > I wanted to try that out, but it turns out that all of my SyncML-capable<br> > phones are dead, i.e. I can no longer test the SyncML over OBEX code. I<br> > already bought a cheap used one via eBay, but that also was dead. I'll<br> > try with another one...<br> <br> I now have a phone again and can reproduce the issue.<br> <br> But some additional debug output shows that OBEX_HandleInput is called<br> after OBEX_Request:<br> <br> [DEVELOPER 00:00:02] OBEX Transport: get header who from connect response with value SYNCML-SYNC<br> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): is ready<br> [ERROR 00:00:02] GLib: Source ID 2 was not found when attempting to remove it<br> [INFO 00:00:02] Server sending SAN<br> [DEVELOPER 00:00:02] ObexTransport send is called (116 bytes)<br> [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_Request for OBEX_CMD_PUT<br> [DEVELOPER 00:00:02] ObexTransportAgent::wait(reply)<br> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration<br> [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput<br> [DEVELOPER 00:00:02] OBEX_EV_PROGRESS<br> [DEVELOPER 00:00:02] ObexTransportAgent::wait(): iteration<br> [DEVELOPER 00:00:02] ObexTransportAgent: OBEX_HandleInput<br> ^C<br> [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration<br> [DEBUG 00:00:05] SuspendFlags: read 7 from fd 5<br> [DEBUG 00:00:05] reveived signal 2<br> [DEBUG 00:00:05] CancelTransport: cancelling because of SuspendFlags::ABORT<br> [DEVELOPER 00:00:05] ObexTransportAgent::shutdown()<br> [DEVELOPER 00:00:05] ObexTransportAgent::wait(no reply)<br> [DEVELOPER 00:00:05] ObexTransportAgent::wait(): iteration<br> [DEVELOPER 00:00:05] ObexTransportAgent: OBEX_HandleInput<br> *** buffer overflow detected ***: install_new_openobex/bin/syncevolution terminated<br> <br> The buffer overflow is happening inside the new libopenobex after<br> SyncEvolution called OBEX_CancelRequest and while SyncEvolution is<br> waiting for the pending command to finish. This does not happen with the<br> old libopenobex.<br> <br> That aside, the key point is that it's not getting stuck because of the<br> issue mentioned in the openobex 1.7 release notes. Wireshark also shows<br> that some data goes out. Unfortunately it stop decoding data at the<br> RFCOMM level, so it's not immediately obvious what's going on for OBEX.<br> <br> The next step was to try with an older libopenobex. I force-installed an<br> old libopenobex1-dev and libopenobex; that didn't install cleanly, but<br> the files seemed to be in place and it was possible to link against<br> them. However, the resulting binary then got stuck the same way (but<br> allowed to abort cleanly).<br> <br> I also tried running the last stable release inside Docker:<br> <br> <br> docker run --rm -ti --net=host --privileged --volume \<br> /home/pohly/.config:/config \<br> --volume \<br> /tmp/syncevolution-bundle_1.5.3-2_amd64.deb:/tmp/syncevolution-bundle_1.5.3-2_amd64.deb \<br> --volume /dev:/dev --volume /sys:/sys debian:stretch<br> <br> And inside it:<br> <br> apt-get update && apt-get install /tmp/syncevolution-bundle_1.5.3-2_amd64.deb -f<br> XDG_CONFIG_HOME=/config SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --sync refresh-from-remote --sync-property loglevel=10 NokiaPhone<br> <br> But that segfaults while preparing the SAN, i.e. even earlier.<br> <br> ==2063== Process terminating with default action of signal 11 (SIGSEGV): dumping core<br> ==2063== Bad permissions for mapped region at address 0x7F0E358<br> ==2063== at 0x7F0E358: ??? (in /usr/lib/libsmltk.so.0.6.0)<br> ==2063== by 0x56A87B5: sysync::newPCDataStringX(unsigned char const*, bool, int) (sysync_utils.cpp:2992)<br> ==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)<br> ==2063== by 0x56224C6: SyncEvo::SyncContext::sendSAN(unsigned short) (SyncContext.cpp:3642)<br> ==2063== by 0x562A6A2: SyncEvo::SyncContext::doSync() (SyncContext.cpp:3829)<br> ==2063== by 0x5631338: SyncEvo::SyncContext::sync(SyncEvo::SyncReport*) (SyncContext.cpp:3446)<br> ==2063== by 0x55AB3D6: SyncEvo::Cmdline::run() (Cmdline.cpp:1726)<br> ==2063== by 0x416823: main (syncevolution.cpp:533)<br> <br> I've never used this particular config before; it's possible that I<br> screwed it up when preparing for syncing with the new phone. But that<br> shouldn't lead to a segfault.<br> <br> I'll have to try next with the old release compiled from source to debug<br> that.<br> <br> -- <br> Best Regards<br> <br> Patrick Ohly<br> </blockquote></div>