On Do, 2011-09-08 at 16:55 +0200, Lukas Zeller wrote:
> Hello Patrick,
>
> On Sep 8, 2011, at 9:59 , Lukas Zeller wrote:
>
> > PS: I'm in the code now :-)
>
> Done, but not tested beyond not interfering with normal operation in my
> context.
>
> Here's the patch, I'm currently shuffling my repos around so I haven't pushed
> it yet.
This applies on top of the previous patch, right?
I had some problems, probably due to white-space cleanup in your branch,
but got it merged with some manual fixing. The patches in my
libsynthesis bmc22783 branch are still needed. In particular the patch
to pluginapids.cpp is needed, otherwise the local ID gets lost on the
way back to the engine.
Note that I decided to not invoke post-write handling in the 409 case,
because no real changes were made in that case.
I've tested the 207 case (SyncEvolution still returned that initially),
with mixed results. The logic in the server seems to get confused and
eventually throws an internal error here:
(gdb) list
1555 dodelete:
1556 fSyncOpElementP->elementType=SML_PE_DELETE;
1557 fCmdType=scmd_delete;
1558 break;
1559 default:
1560 SYSYNC_THROW(TSyncException("Invalid SyncOp in
TSyncOpCommand"));
1561 //break;
1562 } // switch
1563 } // TSyncOpCommand::TSyncOpCommand
#0 0x00007f7d8eb90230 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1 0x0000000000ad1f77 in
sysync::TSyncOpCommand::TSyncOpCommand(sysync::TSyncSession *,
sysync::TLocalEngineDS *, sysync::<anonymous enum>, SmlPcdataPtr_t)
(this=0x1c3b210, aSessionP=0x184ce50, aDataStoreP=0x1bef4c0,
aSyncOp=875770417, aMetaP=0x180d6a0) at
/home/pohly/syncevolution/libsynthesis/src/sysync/synccommand.cpp:1560
#2 0x0000000000a759c2 in sysync::TLocalEngineDS::newSyncOpCommand
(this=0x1bef4c0, aSyncItemP=0x182b4a0,
aSyncItemTypeP=0x1c3b3a0, aLocalIDPrefix=0x0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:4624
#3 0x0000000000aba120 in
sysync::TStdLogicDS::logicGenerateSyncCommandsAsServer (this=0x1bef4c0,
aNextMessageCommands=..., aInterruptedCommandP=@0x1af2360,
aLocalIDPrefix=0x0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/stdlogicds.cpp:870
#4 0x0000000000a70895 in sysync::TLocalEngineDS::engGenerateSyncCommands
(this=0x1bef4c0,
aNextMessageCommands=..., aInterruptedCommandP=@0x1af2360,
aLocalIDPrefix=0x0)
at /home/pohly/syncevolution/libsynthesis/src/sysync/localengineds.cpp:3070
#5 0x0000000000acfc60 in sysync::TSyncCommand::generateCommandsAndClose
(this=0x1af2310)
at /home/pohly/syncevolution/libsynthesis/src/sysync/synccommand.cpp:983
The bad sync op enum comes from a sync item pointer in
TStdLogicDS::logicGenerateSyncCommandsAsServer() which no longer seems
to be valid:
(gdb) p *syncitemP
$14 = {_vptr.TSyncItem = 0x20, fRemoteID = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>}, _M_p = 0x20 <Address 0x20 out of
bounds>}}, fLocalID = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> =
{<No data fields>}, <No data fields>}, _M_p = 0x0}}, fSyncOp = 875770417,
fSyncItemTypeP = 0x5e25242340213039}
The sync then aborts and during flushing the current state for a suspend
segfaults when trying to read the bogus 0x20 local ID pointer.
At the point where 207 is processed, should it really conclude that no
update is needed? Here's the log:
[2011-09-12 15:53:49.159] InsertItemAsKey res=207
* [2011-09-12 15:53:49.159] Database adapter indicates that added
item was merged with pre-existing data (status 207)
* [2011-09-12
15:53:49.159] TStdLogicDS::getConflictingItemByLocalID, found
RemoteID='1234567890!@#$%^&*()<>@dummy-rid',
LocalID='1234567890!@#$%^&*()<>@dummy-rid', syncop=add
* [2011-09-12 15:53:49.159] Preventing localID='1234567890!@#$%
^&*()<>@dummy-rid' to be sent to client
* [2011-09-12 15:53:49.159] Item with localID='1234567890!@#$%
^&*()<>@dummy-rid' will NOT be sent to client (slowsync match /
duplicate prevention)
* [2011-09-12 15:53:49.159] Created command 'Status' (outgoing)
* [2011-09-12 15:53:49.161] ReadItemAsKey aID=(1234567890!@#$%
^&*()<>@dummy-rid,) res=0
* +–[2011-09-12 15:53:49.161] 'ScriptExecute' - Start executing
Script, name=afterreadscript [--][++] [->end] [->enclosing]
* [...]
'ScriptExecute' [->top] [->enclosing]
* [2011-09-12 15:53:49.166] Forced conflict with corresponding
item from server DB
* [2011-09-12 15:53:49.166] Deleted command 'Status' (outgoing
MsgID=0, CmdID=0)
* [2011-09-12 15:53:49.166] ModifyMap called: aEntryType=normal,
aLocalID='1234567890!@#$%^&*()<>@dummy-rid,
aRemoteid='1234567890!@#$%^&*()<>@dummy-rid', aMapflags=0x0,
aDelete=0
* [2011-09-12 15:53:49.166] - found no matching entry for localID
'1234567890!@#$%^&*()<>@dummy-rid' - creating new one,
added=true
* [2011-09-12 15:53:49.166] - Operation add performed (regular),
Remote ID=1234567890!@#$%^&*()<>@dummy-rid Local ID=1234567890!
@#$%^&*()<>@dummy-rid, status=201
* [2011-09-12 15:53:49.166] Deleted command 'Status' (outgoing
MsgID=0, CmdID=0)
–[2011-09-12 15:53:49.166] End of 'Process_Item' [->top] [->enclosing]
As discussed before, 207 isn't really what SyncEvolution does. So next I
tried DB_DataReplaced = 208. That worked as expected. When extending my
testing so that the client's item is older than the server's, 208 fails
as expected: the out-dated data from the Add overwrites the more recent
local data.
So next is DB_Conflict = 409. The merge+update itself works. It seemed
to go down a similar code path as 207, but didn't crash.
The only remaining question is: should the merge take full advantage of
the age information available in this case ("newer wins") or merge data
on a per-property basis for those which support it (multi-line +
merge=lines)?
What I see is right now is that for SUMMARY, the most recent value is
used (good!). DESCRIPTION and LOCATION get concatenated, with older
value first. That's not bad, I just wonder.
The SyncEvolution config is:
<field name="DMODIFIED" type="timestamp" compare="never" age="yes"/>
[...]
<field name="SUMMARY" type="multiline" compare="always"/>
<field name="DESCRIPTION" type="multiline" compare="slowsync"
merge="lines"/>
<field name="LOCATION" type="multiline" compare="slowsync" merge="lines"/>
So I guess the engine works as expected. In the case of iCalendar 2.0 I
wonder whether merge=lines is needed. For modify/modify conflicts
perhaps, but not so much for add/add conflicts. Thoughts?
--
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.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
