On Mo, 2011-09-12 at 20:33 +0200, Patrick Ohly wrote:
> 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 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.
This is because of TCustomImplDS::implProcessItem():
// if backend has not replaced, but merely merged data, we're done.
Otherwise, client needs to be updated with
// merged/augmented version of the data
if (sta!=DB_DataReplaced) {
// now create a replace command to update the item added from the
client with the merge result
// - this is like forcing a conflict, i.e. this loads the item by
local/remoteid and adds it to
// the to-be-sent list of the server.
if (augmentedItemP) {
// augmented version was created in engine, just add that
version to the list of items to be sent
SendItemAsServer(augmentedItemP); // takes ownership of
augmentedItemP
augmentedItemP = NULL;
}
else {
// augmented version was created in backend, fetch it now and
add to list of items to be sent
===> augmentedItemP = (TMultiFieldItem
*)SendDBVersionOfItemAsServer(myitemP);
}
}
sta = LOCERR_OK; // otherwise, treat as ok
}
#endif
} // server
// - we don't need the augmented item any more if it still exists at
this point
if (augmentedItemP) {
====> delete augmentedItemP; augmentedItemP = NULL;
}
The 207 code path goes through the two marked lines. I suppose setting
augmentedItemP in the first line is wrong? It's not needed and must not
be freed.
--
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
