Replace several Q_ASSERTs with proper checks
ClosedPublic

Authored by bruns on Apr 19 2018, 12:51 AM.

Details

Summary

The code has some preconditions on supplied values when interacting
with the DB. Instead of silently corrupting the DB with bogus values
when using non-debug builds, check any provided arguments.

Diff Detail

Repository
R293 Baloo
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
bruns created this revision.Apr 19 2018, 12:51 AM
Restricted Application added projects: Frameworks, Baloo. · View Herald TranscriptApr 19 2018, 12:51 AM
Restricted Application added a subscriber: Frameworks. · View Herald Transcript
bruns requested review of this revision.Apr 19 2018, 12:51 AM
broulik added inline comments.
src/engine/documenturldb.cpp
107–109

Didn't you mean id?

172–174

Put docId check first for consistency

bruns updated this revision to Diff 33171.Apr 26 2018, 8:32 PM

fix variable name

bruns marked 2 inline comments as done.Apr 26 2018, 8:33 PM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald TranscriptSep 29 2018, 12:57 PM
apol added subscribers: sitter, apol.Sep 29 2018, 3:01 PM

If it was silently corrupting the DB maybe the right solution would have been to integrate baloo properly with KCrash.
Like @sitter did in https://phabricator.kde.org/D15573.

src/engine/documenturldb.cpp
44–46

Would it make sense to include a warning then? If it's a wrong input, we'll need ways to debug it now that it won't be giving a backtrace.

bruns added inline comments.Sep 29 2018, 3:14 PM
src/engine/documenturldb.cpp
44–46

This may be accessed quite frequently, so we would get a lot of warnings, spamming the journal, and slowing down the system.

A backtrace is useless here, as the code processes whatever it finds in the database. The interesting part is how the bad data ended up in the db.

Doing the checks here avoids spreading any existing corruption.

The long term solution is to:

  1. Find the bugs leading to the DB corruption
  2. Run lowlevel and highlevel sanity checks on existing databases

Both are on my TODO list, but this will take some time.

apol added inline comments.Sep 29 2018, 4:41 PM
src/engine/documenturldb.cpp
44–46

Shouldn't asserts help to find where the library is being misused?

bruns added inline comments.Sep 29 2018, 5:11 PM
src/engine/documenturldb.cpp
44–46

You gain no information if you crash here. Not the code is wrong, but the processed data.

Most importantly, when somebody runs this code, compiled without DEBUG, we will run into more and more silent corruption.

As soon as baloo is in a state where it is selfhealing, adding logging becomes an option, currently it is not.

bruns added a comment.Feb 27 2019, 2:01 AM
In D12336#333853, @apol wrote:

If it was silently corrupting the DB maybe the right solution would have been to integrate baloo properly with KCrash.
Like @sitter did in https://phabricator.kde.org/D15573.

Silently - it does not crash, garbage data ends up in the database for (mostly) unknown reasons.

Only known reason for zero IDs are races due to renames and similar, where e.g. a file is added with some path, and the parent does not exist microseconds later (at least not under the previous name).

bruns edited reviewers, added: ngraham, poboiko; removed: michaelh.Feb 27 2019, 9:21 PM
dhaumann accepted this revision.EditedFeb 28 2019, 8:58 PM
dhaumann added a subscriber: dhaumann.

I am very much in favour of this change.

In fact, we had this discussion already a long time ago on the mailing list, namely that baloo has (had?) zero error handling and simply assuming that everything works by adding some Q_ASSERTS.

@bruns You are working on this code for quite a time now. I trust you know very much what you are doing much more than possibly anyone else. I know that you would like to get a better review, but having a review open for 5+ months clearly shows we have an issue elsewhere.

Please proceed and commit - I am taking the liberty to give a +2: If there are other issues, then these can still be fixed in followup commits.

This revision is now accepted and ready to land.Feb 28 2019, 8:58 PM
This revision was automatically updated to reflect the committed changes.