[SyncEvolution] Help needed

[deloptes]

Thank you once again,

Patrick Ohly wrote:

> On Mon, 2016-02-29 at 01:34 +0100, deloptes wrote:
>> >> 
>> >> So in the LocalTransportAgent
>> >> 
>> >> we have
>> >> 
>> >>             while (! m_reportSent  && m_parent && s.getState() ==
>> >> SuspendFlags::NORMAL ) {
>> >>                step("waiting for parent's ACK for sync report");
>> >>             }
>> >> 
>> >> which never completes.
>> > 
>> > Yes, that's where the "waiting for parent's ACK for sync report" comes
>> > from that we've seen earlier in a stack backtrace.
>> > 
>> 
>> Right before the loop it says
>> m_parent->m_storeSyncReport.start(report,
>> boost::bind(&LocalTransportAgentChild::syncReportReceived, this, _1));
>> 
>> but I do not see "sending sync report to parent" in the log
>> It looks like it never gets called or something else, so m_reportSent
>> stays false and the loop never ends. I am afraid I was wrong about this
>> previous time , or perhaps confused.
> 
> Does the parent receive the sync report? There should be a "got child
> sync report" message from LocalTransportAgent::storeSyncReport().

I'm not sure. I guess we are trying to find out. In my opinion no.

> 
> This looks like a low-level D-Bus communication problem between child
> and parent. Why that happens is a complete mystery.

Yes - mystery - my whole life has been such one :)

> 
> Did you compile with glib dbus or libdbus? Probably glib dbus, it is the
> default. Then you can enable additional debug output for that internal
> D-Bus communication with:
> G_DBUS_DEBUG=call,return,payload
> 
> Always combine that with SYNCEVOLUTION_DEBUG=1.
> 
> Watch out for a method-call to "StoreSyncReport". It should appear
> twice: once when getting send by the child, once when received by the
> parent. For that message, a corresponding method-return message should
> be sent by parent to child, again being logged twice.

This is there once (but better have a look yourself, please). I attach gz.
There is also 'method-return' and there it stops

> 
> This return message should trigger the
> LocalTransportAgentChild::syncReportReceived callback.

... but this never happens

> 
>> After I terminate I do not see this in the logs. I see "waiting for
>> parent's ACK for sync report" only in the backtrace.
>> I also do not see "child sending sync report" in the log.
>> 
>> Do you mean I should upload/attach some log (the html ones?)
> 
> I meant the text output from "SYNCEVOLUTION_DEBUG=1 syncevolution
> --daemon=no loglevel=10 ..." - the one which has the SE_LOG_DEBUG()
> output.
> 
>> > Which close() function?
>> > 
>> 
>> I mean "TrackingSyncSource::close()" implemented in the plugin.
>> 
>> If I understand correctly I should put there the logic for saving
>> changes. In open() I set the resource/database and request a ticket,
>> which would close saving all changes if only close() would have been
>> called. In the log/dbg I see open finishing but no trace of close().
>> This could be related to the above problem as well, but please confirm
>> that I understand the usage properly.
> 
> You are right. However, close() is typically called very late. It might
> be better to ensure earlier that requested changes really get written
> persistently. There's a TrackingSyncSource::flush() method for that.
> 
>     /**
>      * optional: write all changes, throw error if that fails
>      *
>      * This is called while the sync is still active whereas
>      * close() is called afterwards. Reporting problems
>      * as early as possible may be useful at some point,
>      * but currently doesn't make a relevant difference.
>      */
>     virtual void flush() {}
>     
>     /**
>      * closes the data source so that it can be reopened
>      *
>      * Just as open() it should not affect the state of
>      * the database unless some previous action requires
>      * it.
>      */
>     virtual void close() = 0;
> 

I have seen the flush function, however the tde/kde3 logic is such that it
would cleanup the pointers when ticket gets saved and in my opinion the
best is to do it in close() as opposed to open(). If all works fine it
would be sufficient, but thank you for the advise anyway.

I also added some from the html log at the end of the file with
corresponding source.
Both sides say:
"Never received status for command 'SyncHdr', (outgoing MsgID=4, CmdID=0)"
"Never received status for command 'SyncHdr', (outgoing MsgID=3, CmdID=0)"

Is this OK? It leads to  TSyncSession::InternalResetSessionEx

// reset session to inital state (new)
......

regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: syncevo_dbus.log.gz
Type: application/gzip
Size: 41770 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/syncevolution/attachments/20160229/0010b467/attachment.gz>
-------------- next part --------------
_______________________________________________
SyncEvolution mailing list
SyncEvolution at syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution