Bug 58383 - ObexTransport: exception thrown in sdp_source_cb
Summary: ObexTransport: exception thrown in sdp_source_cb
Status: RESOLVED NOTOURBUG
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: SyncEvolution (show other bugs)
Version: 1.3.99.2
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-17 02:56 UTC by Kip Warner
Modified: 2013-01-29 06:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Synchronization log (16.13 KB, text/html)
2012-12-17 02:56 UTC, Kip Warner
Details
Synchronization log for 1.3.2 (16.42 KB, text/html)
2012-12-18 01:02 UTC, Kip Warner
Details
SyncEvolution log (15.83 KB, text/html)
2013-01-04 09:48 UTC, Kip Warner
Details
SyncEvolution Log (15.83 KB, text/html)
2013-01-10 00:47 UTC, Kip Warner
Details

Description Kip Warner 2012-12-17 02:56:33 UTC
Created attachment 71619 [details]
Synchronization log

I can no longer sync with my Nokia E71 phone anymore. Synchronization log is attached. Version information follows:

$ syncevolution --version
SyncEvolution 1.3.99.2 (pre-release)
using libedataserver-1.2.so.15
using libebook-1.2.so.12
using libebook-1.2.so.12
using libecal-1.2.so.10
using libecal-1.2.so.10
using libbluetooth.so.3
Loading backend library /usr/lib/syncevolution/backends/platformgnome.so
Loading backend library /usr/lib/syncevolution/backends/platformkde.so
Loading backend library /usr/lib/syncevolution/backends/syncaddressbook.so
Loading backend library /usr/lib/syncevolution/backends/syncakonadi.so
Loading backend library /usr/lib/syncevolution/backends/syncdav.so
Loading backend library /usr/lib/syncevolution/backends/syncebook.so
Loading backend library /usr/lib/syncevolution/backends/syncecal.so
Loading backend library /usr/lib/syncevolution/backends/syncfile.so
Loading backend library /usr/lib/syncevolution/backends/synckcalextended.so
Loading backend library /usr/lib/syncevolution/backends/syncmaemocal.so
Loading backend library /usr/lib/syncevolution/backends/syncpbap.so
Loading backend library /usr/lib/syncevolution/backends/syncqtcontacts.so
Loading backend library /usr/lib/syncevolution/backends/syncsqlite.so
Loading backend library /usr/lib/syncevolution/backends/syncxmlrpc.so
Comment 1 Patrick Ohly 2012-12-17 21:20:05 UTC
(In reply to comment #0)
> Created attachment 71619 [details]
> Synchronization log
> 
> I can no longer sync with my Nokia E71 phone anymore.

When did it break? After upgrading to the 1.3.99.2 pre-release?

Can you check whether 1.3.2 works?
Comment 2 Kip Warner 2012-12-18 01:02:10 UTC
Sure. I've attached the log using 1.3.2.

$ syncevolution --version
SyncEvolution 1.3.2
using libedataserver-1.2.so.15
using libebook-1.2.so.12
using libebook-1.2.so.12
using libecal-1.2.so.10
using libecal-1.2.so.10
using libbluetooth.so.3
Loading backend library /usr/lib/syncevolution/backends/syncqtcontacts.so
Loading backend library /usr/lib/syncevolution/backends/syncebook.so
Loading backend library /usr/lib/syncevolution/backends/syncsqlite.so
Loading backend library /usr/lib/syncevolution/backends/platformkde.so
Loading backend library /usr/lib/syncevolution/backends/syncaddressbook.so
Loading backend library /usr/lib/syncevolution/backends/syncakonadi.so
Loading backend library /usr/lib/syncevolution/backends/syncfile.so
Loading backend library /usr/lib/syncevolution/backends/syncecal.so
Loading backend library /usr/lib/syncevolution/backends/syncxmlrpc.so
Loading backend library /usr/lib/syncevolution/backends/synckcalextended.so
Loading backend library /usr/lib/syncevolution/backends/syncmaemocal.so
Loading backend library /usr/lib/syncevolution/backends/platformgnome.so
Loading backend library /usr/lib/syncevolution/backends/syncdav.so
Comment 3 Kip Warner 2012-12-18 01:02:42 UTC
Created attachment 71706 [details]
Synchronization log for 1.3.2
Comment 4 Patrick Ohly 2012-12-18 19:25:10 UTC
(In reply to comment #2)
> Sure. I've attached the log using 1.3.2.

That also fails, so it's not the SyncEvolution update which broke something.

Can you trace it to some other change in your system?

Have you tried rebooting the phone and pairing it again with your computer? Does file transfer via Bluetooth work?
Comment 5 Kip Warner 2012-12-18 23:51:02 UTC
Hey Patrick. Something is definitely wrong, and as you alluded, it might be deeper than SyncEvolution. When I tried to send a file, it just said request timeout. I tried unpairing, re-pairing, then sync'ing again but still get the same error. Is there a directory (I'm running Ubuntu) that contains all of my bluetooth configuration that I could purge?
Comment 6 Kip Warner 2013-01-02 05:19:12 UTC
Hey Patrick. Any news? Still cannot sync. Happy new year, by the way.
Comment 7 Patrick Ohly 2013-01-02 07:49:51 UTC
(In reply to comment #6)
> Hey Patrick. Any news? Still cannot sync. Happy new year, by the way.

I didn't consider this a bug in SyncEvolution and therefore didn't pay much attention. Did you file bugs against your distro regarding this?

Now that you asked again, I remembered something:

https://bugs.launchpad.net/ubuntu/oneiric/+source/obexd/+bug/872044/comments/62

Is that likely? You did not respond to my question whether you had made other changes to your system, like updating the kernel.

Workaround:
sudo hciconfig hci0 sspmode 0

Try unpairing and re-pairing after that.
Comment 8 Kip Warner 2013-01-03 01:46:59 UTC
Hey Patrick. Sorry, I missed your question. I've done kernel updates, but only standard distro packages. I haven't tweaked or patched anything manually myself.

Your fix seemed to work. Thanks a lot. I can finally sync everything again.
Comment 9 Kip Warner 2013-01-03 01:49:12 UTC
One thing I have noticed though is each time I run...

$ syncevolution MyPhone

...it seems to do a long full sync every time which takes maybe more than 10-15 minutes. I deleted the ~/.config/syncevolution directory before doing this.
Comment 10 Patrick Ohly 2013-01-03 12:44:46 UTC
(In reply to comment #9)
> One thing I have noticed though is each time I run...
> 
> $ syncevolution MyPhone
> 
> ...it seems to do a long full sync every time which takes maybe more than
> 10-15 minutes. I deleted the ~/.config/syncevolution directory before doing
> this.

Does it report a slow sync when it's done?

Please send me the syncevolution-log.html file of such an unexpected slow sync.
Comment 11 Kip Warner 2013-01-03 23:50:02 UTC
It's still syncing right now, but here's the beginning of the console output. If it's not enough and you need more, such as the log, let me know:

$ syncevolution MyPhone
[INFO] Server sending SAN
[INFO] calendar: starting first time sync, two-way (peer is client)
[INFO] todo: starting first time sync, two-way (peer is client)
[INFO] addressbook: starting first time sync, two-way (peer is client)
[INFO] memo: starting first time sync, two-way (peer is client)
[INFO] creating complete data backup of source calendar before sync (enabled with dumpData and needed for printChanges)
Local data changes to be applied during synchronization:
*** calendar ***
Comparison was impossible.

[INFO] creating complete data backup of source todo before sync (enabled with dumpData and needed for printChanges)
*** todo ***
Comparison was impossible.

[INFO] calendar: started
[INFO] todo: started
[INFO] updating "Some event"
[INFO] calendar: received 1/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 2/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 3/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 4/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 5/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 6/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 7/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 8/2769
[INFO] calendar: added 0, updated 1, removed 0
[INFO] calendar: received 9/2769
...
Comment 12 Patrick Ohly 2013-01-04 08:21:03 UTC
Looks like a normal, initial sync. How does it end?

There have been issues with phones misbehaving in such a way that the session never properly closes. Does it help to use one of the refresh sync modes? Try that separately for each source.
Comment 13 Kip Warner 2013-01-04 09:48:15 UTC
Well, I tried to sync again to replicate the last result and show you how it ended, but I wasn't able to. Log attached.
Comment 14 Kip Warner 2013-01-04 09:48:39 UTC
Created attachment 72500 [details]
SyncEvolution log
Comment 15 Kip Warner 2013-01-04 09:50:04 UTC
$ sudo hciconfig hci0 sspmode
[sudo] password for kip: 
hci0:	Type: BR/EDR  Bus: USB
	BD Address: <...>  ACL MTU: 310:10  SCO MTU: 64:8
	Simple Pairing mode: Disabled
Comment 16 Patrick Ohly 2013-01-07 14:35:23 UTC
(In reply to comment #14)
> Created attachment 72500 [details]
> SyncEvolution log

In other words, back to square one. To me it looks like your phone is acting up. Try resetting it, then do a refresh sync of one source after the other.
Comment 17 Kip Warner 2013-01-07 20:18:10 UTC
Ok. One thing I was confused about from the man page was on how to force a normal sync, not a slow one?
Comment 18 Patrick Ohly 2013-01-08 07:31:10 UTC
(In reply to comment #17)
> Ok. One thing I was confused about from the man page was on how to force a
> normal sync, not a slow one?

You cannot force a normal, incremental sync unless there was a successful slow sync first.

A refresh sync is a one-way slow sync.

Use "syncevolution --sync refresh-from-local MyPhone addressbook" to refresh the phone's address book from the data on your computer. "refresh-from-remote" would replace the local data - use that if the data on your computer is older.
Comment 19 Kip Warner 2013-01-10 00:46:42 UTC
Thanks Patrick. I'll note that for future reference. In any case, when I tried to sync again, I got the following error in the latest log. Note that I ran the following prior:

$ sudo hciconfig hci0 sspmode 0
Comment 20 Kip Warner 2013-01-10 00:47:23 UTC
Created attachment 72764 [details]
SyncEvolution Log
Comment 21 Kip Warner 2013-01-15 21:26:15 UTC
Hey Patrick. I think the safest thing to do might be to just sync from now on over usb. I wonder if that might be a lot more reliable. Can that be done?
Comment 22 Patrick Ohly 2013-01-15 21:46:17 UTC
(In reply to comment #21)
> Hey Patrick. I think the safest thing to do might be to just sync from now
> on over usb. I wonder if that might be a lot more reliable. Can that be done?

Syncing over USB is not standardized and not supported by SyncEvolution.

I also doubt whether it would work better - if the peer is in a broken state, it's likely to be broken regardless of the transport.
Comment 23 Kip Warner 2013-01-15 22:05:22 UTC
*sigh* Not sure what to do then.
Comment 24 Kip Warner 2013-01-25 21:37:51 UTC
Hey Patrick. I'm still at square one. I've tried resetting the phone, rebooting the computer, disabling sspmode, repairing, installed several different kernels, but still get errors like the following:

[ERROR] transport problem: SDP connection end unexpectedly
[ERROR] transport problem: OBEX/Bluetooth transport error or problem on the peer

Even if there is a problem that is deeper than syncevolution, the error message it is emitting are not very helpful.
Comment 25 Patrick Ohly 2013-01-26 21:27:57 UTC
(In reply to comment #24)
> Hey Patrick. I'm still at square one. I've tried resetting the phone,
> rebooting the computer, disabling sspmode, repairing, installed several
> different kernels,

I don't think it has anything to do with the host.

Have you tried "refresh-from-local" syncing of specific sources, for example the address book?

If everything else fails, can you do a factory reset? Mind you, there's no guarantee that you'll be able to put the data back on via SyncML afterward. But it should help if the phone is really in a broken state.

> but still get errors like the following:
> 
> [ERROR] transport problem: SDP connection end unexpectedly
> [ERROR] transport problem: OBEX/Bluetooth transport error or problem on the
> peer
> 
> Even if there is a problem that is deeper than syncevolution, the error
> message it is emitting are not very helpful.

SyncEvolution is reporting everything that it sees (= "phone has disconnected"). OBEX does not provide further error information in this case.
Comment 26 Kip Warner 2013-01-27 01:55:47 UTC
> I don't think it has anything to do with the host.

The phone hasn't changed though. It's an old Nokia E71 and I haven't gotten any system updates on it since I got it ages ago. Nothing that I can think of, of any import, has changed on it.

> Have you tried "refresh-from-local" syncing of specific sources, for example
> the address book?

I can't do that because it would still need to connect with the phone, but it seems to choke every time that happens before any kind of synchronization can take place.

> If everything else fails, can you do a factory reset? Mind you, there's no
> guarantee that you'll be able to put the data back on via SyncML afterward. 
> But it should help if the phone is really in a broken state.
 

I'd rather not do a factory reset because I would lose all my settings and there is no guarantee that that will solve the problem.

> SyncEvolution is reporting everything that it sees (= "phone has
> disconnected"). OBEX does not provide further error information in this case.

=( *sigh*
Comment 27 Patrick Ohly 2013-01-27 13:28:30 UTC
(In reply to comment #26)
> > I don't think it has anything to do with the host.
> 
> The phone hasn't changed though.

But the data is different now. Perhaps it runs out of memory while processing the increased amount of data, or fails to handle one particular item.
Comment 28 Kip Warner 2013-01-28 00:15:19 UTC
> But the data is different now. Perhaps it runs out of memory while processing > the increased amount of data, or fails to handle one particular item.

Yes, those are distinctive possibilities. Do you have any suggestion for finding either of those out?
Comment 29 Patrick Ohly 2013-01-28 12:22:23 UTC
(In reply to comment #28)
> > But the data is different now. Perhaps it runs out of memory while processing > the increased amount of data, or fails to handle one particular item.
> 
> Yes, those are distinctive possibilities. Do you have any suggestion for
> finding either of those out?

The factory reset was the brute-force suggestion for finding out whether the data is the problem. If you don't want to do that, perhaps you can wipe out data for individual apps manually?
Comment 30 Kip Warner 2013-01-29 06:14:49 UTC
(In reply to comment #29)
> The factory reset was the brute-force suggestion for finding out whether the
> data is the problem. If you don't want to do that, perhaps you can wipe out
> data for individual apps manually?

Factory reset is definitely not an option. I'd wipe out individual data, but I don't know what specifically is making it choke and there are thousands of calendar entries and hundreds of contacts.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.