Taking over maintainership of Baloo

[Boudhayan Gupta]

Hi,

On 11 September 2016 at 22:59, Christoph Cullmann <cullmann at absint.com> wrote:
> I think the main issue is: There is no need to reproduce them, it is clear, that baloo will crash
> on any problem with lmdb, as "no" errors are handled (or lets say 99% of the errors are not handled).
>
> The code is full of Q_ASSERT, but no handling of the return codes beside that.

Oh, it gets worse. Q_ASSERTs compile to nothing in release mode so you
don't even have meaningful crashes on those asserts, things just
mysteriously fail elsewhere. I spent a whole bunch of time coding in
actual checks after those asserts because Dolphin would crash when
selecting multiple files with Baloo disabled, and other such magical
bugs.

> Actually, I think, in most cases the code shall just catch the error cases and do nothing (or purge data
> until all is fine again) but not like now: crash or assert.
>
> That is not acceptable for something that runs per default ;=)
>
> Just looking at the code, you see things like:
>
> 1) Baloo::Database: needs a mutex, as many threads might call ::open (e.g. in krunner) => corruption, dead
>
> 2) inproper cleanup: I doubt one can  mdb_txn_abort(txn); if already mdb_txn_begin(...) failed
>
> 3) needs everywhere return code checks, e.g. in PostingList PostingDB::get(const QByteArray& term), we have
> tons of bugs about random crashs afterwards: https://bugs.kde.org/show_bug.cgi?id=367480
>
> 4) 32-bit systems supported at all? ATM, after 1GB of indexing, that was it, no more baloo or any other application
> calling any of the accessors of e.g. Query (if you have bad luck).

If you have the time to fix those things you've listed above, awesome
- I'd love to look at the RRs. Lessens my workload.

Otherwise I'll look at this on the weekends when I have no sysadmin
things to do.

>
>>
>>> Beside that, could we get some baloo-bugs at kde.org list as default assignee
>>> for all baloo bugs instead of "one" person?
>>
>> If we're going to do it this way, why not just make it the default
>> frameworks mailing list, or the frameworks bugs list if there is one?
> I am not sure, if that will make people happy ;=)

Let's get other people involved, too ;-)

Thanks,
Boudhayan