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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis