Avoid QByteArray::fromRawData

Review Request #125362 - Created Sept. 23, 2015 and submitted

Information
Igor Poboiko
baloo
Reviewers
baloo

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)

After applying this patch I have no more files in wrong category, so the issue is gone.

Issues

  • 1
  • 0
  • 0
  • 1
Description From Last Updated
this just appens the above, so it should be fine as long as list.last() is not empty (unlikely?). So here, ... Milian Wolff Milian Wolff
Vishesh Handa
Milian Wolff
Vishesh Handa
Igor Poboiko
Review request changed

Status: Closed (submitted)

Change Summary:

Submitted with commit 22f1ccfb0496c3dabb87acaa815a32f724c3013a by Igor Poboiko to branch master.
Loading...