From patrick.ohly at intel.com Sun Oct 1 19:14:02 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 01 Oct 2017 21:14:02 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: <1506799024.21120.9.camel@intel.com> References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> Message-ID: <1506885242.21120.12.camel@intel.com> On Sat, 2017-09-30 at 21:17 +0200, Patrick Ohly wrote: > 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? Another way to approach this might be to take network traffic dumps with wireshark of the Bluetooth communication with old and new libopenobex, then compare packets. There shouldn't be that many of them yet, at least when it fails. -- 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. From deloptes at gmail.com Tue Oct 3 08:35:17 2017 From: deloptes at gmail.com (deloptes) Date: Tue, 3 Oct 2017 10:35:17 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> Message-ID: Patrick Ohly wrote: > Interesting :-/ Perhaps try running under valgrind to root-cause this > issue? > I was thinking the memory errors in valgrind were related to the tdepim code, but it looks like it fails in the sync process when tdepim crashes. find attached the valgrind output. I will try wireshark on the bt and will come back later. thanks and regards -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output.txt URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Wed Oct 4 08:22:38 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 04 Oct 2017 10:22:38 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> Message-ID: <1507105358.25153.3.camel@intel.com> On Tue, 2017-10-03 at 10:35 +0200, deloptes wrote: > Patrick Ohly wrote: > > > Interesting :-/ Perhaps try running under valgrind to root-cause > > this > > issue? > > > > I was thinking the memory errors in valgrind were related to the > tdepim > code, but it looks like it fails in the sync process when tdepim > crashes. Yes, the TDECrash::defaultCrashHandler is catching some problem and then itself causing valgrind errors. Is there some way to disable the handler? The actual problem seems to be in /usr/lib/x86_64-linux- gnu/libsmltk.so.0.6.0. Having that with debug information would be useful. Typically, during my development work I build with --disable-shared --enable-static and --with-synthesis- src=.../libsynthesis where "libsynthesis" is the source dir of libsynthesis. That way, I get a single executable that has the right compile flags and all code included, i.e. I can set breakpoints right away without having to wait for shared libraries to get loaded. It also avoids problems with picking up system shared libraries. -- 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. From deloptes at gmail.com Fri Oct 6 21:01:49 2017 From: deloptes at gmail.com (deloptes) Date: Fri, 6 Oct 2017 23:01:49 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> Message-ID: Patrick Ohly wrote: > Typically, during my development work I build with > --disable-shared --enable-static and --with-synthesis- > src=.../libsynthesis where "libsynthesis" is the source dir of > libsynthesis. > > That way, I get a single executable that has the right compile flags > and all code included, i.e. I can set breakpoints right away without > having to wait for shared libraries to get loaded. It also avoids > problems with picking up system shared libraries. I think you are more experienced :) at least I understand what you mean. Please note that the reference used with obex1.5 is not build this way. Let me know if I have to do the same with obex1.5 I did include libsynthesis in syncevolution with obex1.7 and got the wireshark capture, but I can understand almost nothing out of it. May I attach the captured traffic? My concern is that IMEI of the phone is in the packets. Here is a brief - the difference starts around packet 92 obex1.5 89 4.306562 localhost () TexasIns_90:56:e3 (Nokia N9 16GB) RFCOMM 53 Sent UIH Channel=25 90 4.314413 controller host HCI_EVT 8 Rcvd Number of Completed Packets 91 5.129409 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () HCI_ACL 517 Rcvd [Reassembled in #92] 92 5.130029 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () RFCOMM 510 Rcvd UIH Channel=25 93 5.133153 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () HCI_ACL 517 Rcvd [Reassembled in #94] 94 5.133650 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () RFCOMM 510 Rcvd UIH Channel=25 95 5.136777 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () HCI_ACL 517 Rcvd [Reassembled in #96] obex1.7 89 3.817533 localhost () TexasIns_90:56:e3 (Nokia N9 16GB) RFCOMM 53 Sent UIH Channel=25 90 3.828868 controller host HCI_EVT 8 Rcvd Number of Completed Packets 91 3.833241 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () RFCOMM 16 Rcvd UIH Channel=25 92 3.877417 localhost () TexasIns_90:56:e3 (Nokia N9 16GB) RFCOMM 13 Sent DISC Channel=25 93 3.897865 controller host HCI_EVT 8 Rcvd Number of Completed Packets 94 3.900738 TexasIns_90:56:e3 (Nokia N9 16GB) localhost () RFCOMM 13 Rcvd UA Channel=25 95 3.900756 localhost () TexasIns_90:56:e3 (Nokia N9 16GB) RFCOMM 13 Sent DISC Channel=0 _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Oct 7 06:11:45 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 07 Oct 2017 08:11:45 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> Message-ID: <1507356705.25153.31.camel@intel.com> On Fri, 2017-10-06 at 23:01 +0200, deloptes wrote: > Patrick Ohly wrote: > Please note that the reference used with obex1.5 is not build this > way. Let > me know if I have to do the same with obex1.5 That would only be necessary if we wanted to debug obex1.5 at the source level. This doesn't seem necessary yet. > I did include libsynthesis in syncevolution with obex1.7 and got the > wireshark capture, but I can understand almost nothing out of it. > May I attach the captured traffic? My concern is that IMEI of the > phone is > in the packets. Perhaps send it to me privately? I'm not sure whether I'll find anything either, though. -- 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. From deloptes at gmail.com Sat Oct 7 17:31:53 2017 From: deloptes at gmail.com (deloptes) Date: Sat, 7 Oct 2017 19:31:53 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> Message-ID: Patrick Ohly wrote: > Perhaps send it to me privately? I'm not sure whether I'll find > anything either, though. Can't we add some debug code in syncevo or obex to get the type of event is causing the trouble? The message I get after including libsynthesis in syncevo is a bit different (more complete) According to last error message the error is thrown here while (!m_obexReady) { g_main_context_iteration (m_context, TRUE); if (m_status == FAILED) { SE_THROW_EXCEPTION (TransportException, "ObexTransprotAgent: Underlying transport error"); } } sync_debug/syncevolution_1.5.2$ SYCNEVOLUTION_DEBUG=10 ./src/syncevolution -r loglevel=6 nokia_N9 addressbook [INFO] calendar: inactive [INFO] calendar+todo: inactive [INFO] memo: inactive [INFO] todo: inactive [INFO] Server sending SAN [ERROR] OBEX Request 3 got a failed response Unknown response [ERROR] GLib: Source ID 2 was not found when attempting to remove it [INFO] Server sending SAN [ERROR] OBEX Request 3 got a failed response Unknown response [ERROR] transport problem: ObexTransprotAgent: Underlying transport error Synchronization failed regards _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sat Oct 7 17:40:50 2017 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sat, 07 Oct 2017 19:40:50 +0200 Subject: [SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch) In-Reply-To: References: <20170727074034.GA18421@eazy.amigager.de> <1501151293.26603.45.camel@intel.com> <1504533179.12799.68.camel@intel.com> <1504545653.12799.70.camel@intel.com> <1504602762.12799.73.camel@intel.com> <1506799024.21120.9.camel@intel.com> <1507105358.25153.3.camel@intel.com> <1507356705.25153.31.camel@intel.com> Message-ID: <1507398050.25153.33.camel@intel.com> On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote: > Patrick Ohly wrote: > > > Perhaps send it to me privately? I'm not sure whether I'll find > > anything either, though. > > Can't we add some debug code in syncevo or obex to get the type of > event is causing the trouble? > The message I get after including libsynthesis in syncevo is a bit > different (more complete) But the initial error is still the same "OBEX Request 3 got a failed response Unknown response". If you can't track down the "Unknown response" interactively in a debugger, then you can of course also add more debug output. -- 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.