Patrick Ohly changed bug 82863
What Removed Added
Status NEEDINFO ASSIGNED

Comment # 7 on bug 82863 from
(In reply to comment #6)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > During synchronization of PBAP peer, suspend sync is failing when PBAP
> > > transfer has finished, but sync is still ongoing.
> > 
> > Out of curiosity, how long does the sync keep running after the download has
> > finished? The sync should finish shortly after the download, so the chance
> > of hitting this time window should be small.
> 
> Please find attached logs from dbus-monitor run in profile mode, during
> incremental and all sync - for incremental sync sync finished 1 second after
> transfer, for all sync it finished 4 seconds after transfer.
> 
> > Is this perhaps with downloading in chunks enabled?
> 
> No, download in chunks is not enabled.
>  
> > You mentioned seeing a NULL pointer access when analyzing this. Where in the
> > source was that and/or what is the exact error when suspending fails?
> 
> You probably misunderstand me, there is no NULL pointer access, I've checked
> with Syncevolution code and saw that error message that I'm getting is
> coming from exception in PbapSession::setFreeze (attached dbus-monitor logs
> with error message, for both incremental and all sync).

Indeed, from what you said I had expected an empty boost::shared_ptr reference
(which leads to an exception); what the log shows is a race condition where
obexd finishes and removes the transfer object at the same time as
SyncEvolution sends a Suspend method call:

method call sender=:1.1 -> dest=org._01.pim.contacts serial=10
path=/org/01/pim/contacts; interface=org._01.pim.contacts.Manager;
member=SuspendSync
   string "htc"
signal sender=:1.7 -> dest=(null destination) serial=25
path=/org/bluez/obex/client/session1/transfer1;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.obex.Transfer1"
   array [
      dict entry(
         string "Transferred"
         variant             uint64 285950
      )
   ]
   array [
   ]
...
signal sender=:1.7 -> dest=(null destination) serial=26
path=/org/bluez/obex/client/session1/transfer1;
interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.bluez.obex.Transfer1"
   array [
      dict entry(
         string "Status"
         variant             string "complete"
      )
   ]
   array [
   ]
signal sender=:1.7 -> dest=(null destination) serial=27 path=/;
interface=org.freedesktop.DBus.ObjectManager; member=InterfacesRemoved
   object path "/org/bluez/obex/client/session1/transfer1"
   array [
      string "org.freedesktop.DBus.Properties"
      string "org.freedesktop.DBus.Introspectable"
      string "org.bluez.obex.Transfer1"
   ]
method call sender=:1.8 -> dest=org.bluez.obex serial=8
path=/org/bluez/obex/client/session1/transfer1;
interface=org.bluez.obex.Transfer1; member=Suspend
error sender=:1.7 -> dest=:1.8
error_name=org.freedesktop.DBus.Error.UnknownObject reply_serial=8
   string "Method "Suspend" with signature "" on interface
"org.bluez.obex.Transfer1" doesn't exist
"

The error string is a bit misleading, it's the object path which does not
exist, not the interface. or method.

Anyway, SyncEvolution doesn't need to check the error. It knows that the
transfer completed at the time when it receives the error, so it can simply
ignore all errors.


You are receiving this mail because: