----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125362/#review86076 -----------------------------------------------------------
Ship it! The more I think I about this, the more it makes sense. I managed to fix one of corruption issues with [this](https://git.reviewboard.kde.org/r/125431/), but who knows how many more exist. The proper solution is to write our own class where the copy / move semantics are cleared. Also most of our strings are quite small and QByteArray does not have any small string optimizations. Ship it! - Vishesh Handa On Sept. 23, 2015, 2:42 p.m., Igor Poboiko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125362/ > ----------------------------------------------------------- > > (Updated Sept. 23, 2015, 2:42 p.m.) > > > Review request for Baloo. > > > Repository: baloo > > > Description > ------- > > I've noted following bug: sometypes e.g "PDF" (T5) files had a "Folder" (T9) > type in KRunner. > "balooshow -x" showed that it has a "T5", while "baloosearch --type folder" > still listed it. > > * Debugging showed that it appears somewhere in WritingTransaction::commit() > * There wasn't any WritingTransaction::m_pendingOperations["T9"] access at > all > * This hash contained "T9" key (QHash::keys().contains("T9") == true), but > it didn't (QHash::contains("T9") == false and QHash::count("T9") == 0) > * Because of that QHashIterator fails miserably iterating over non-existing > values (e.g iter.value() returns some value with some data for that > non-existing values) > * Bisection showed that QHash got corrupted at "documentTermsDB.put(id, > docTerms)" (engine/writingtransaction.cpp:185), to be specific - on mdb_put() > line > > That was the bug itself. The problem is that QByteArray::fromRawData() is > used everywhere, which does not copy data from DB but just stores a pointer > to some place in memory-mapped file in DB. And it doesn't know if data where > it points to changed, leading to undefined behavior like that. > > This patch removes ::fromRawData() calls replacing it by copy-constructors. > (maybe somewhere we can leave it, but I'm not sure it's a optimization we > should care about) > > > Diffs > ----- > > src/codecs/doctermscodec.cpp e8801f9 > src/codecs/postingcodec.cpp 1edb645 > src/engine/documentdatadb.cpp 690df70 > src/engine/documentdb.cpp ea0cb66 > src/engine/idfilenamedb.cpp d4e1eb1 > src/engine/positiondb.cpp 568dc54 > src/engine/postingdb.cpp e183db5 > > Diff: https://git.reviewboard.kde.org/r/125362/diff/ > > > Testing > ------- > > After applying this patch I have no more files in wrong category, so the > issue is gone. > > > Thanks, > > Igor Poboiko > >
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
