<div dir="ltr">Hey Boudhayan,<div><br></div><div>It's nice that you are stepping up for maintaining baloo. I have no objections to that and will try to help you out whenever needed :)</div><div><br></div><div>Cheers,</div><div>Pinak</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>--</div><div>Thanks<br>Pinak Ahuja</div></div></div></div>
<br><div class="gmail_quote">On 11 September 2016 at 19:40, Boudhayan Gupta <span dir="ltr"><<a href="mailto:bgupta@kde.org" target="_blank">bgupta@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On 11 September 2016 at 22:59, Christoph Cullmann <<a href="mailto:cullmann@absint.com">cullmann@absint.com</a>> wrote:<br>
> I think the main issue is: There is no need to reproduce them, it is clear, that baloo will crash<br>
> on any problem with lmdb, as "no" errors are handled (or lets say 99% of the errors are not handled).<br>
><br>
> The code is full of Q_ASSERT, but no handling of the return codes beside that.<br>
<br>
</span>Oh, it gets worse. Q_ASSERTs compile to nothing in release mode so you<br>
don't even have meaningful crashes on those asserts, things just<br>
mysteriously fail elsewhere. I spent a whole bunch of time coding in<br>
actual checks after those asserts because Dolphin would crash when<br>
selecting multiple files with Baloo disabled, and other such magical<br>
bugs.<br>
<span class=""><br>
> Actually, I think, in most cases the code shall just catch the error cases and do nothing (or purge data<br>
> until all is fine again) but not like now: crash or assert.<br>
><br>
> That is not acceptable for something that runs per default ;=)<br>
><br>
> Just looking at the code, you see things like:<br>
><br>
> 1) Baloo::Database: needs a mutex, as many threads might call ::open (e.g. in krunner) => corruption, dead<br>
><br>
> 2) inproper cleanup: I doubt one can  mdb_txn_abort(txn); if already mdb_txn_begin(...) failed<br>
><br>
> 3) needs everywhere return code checks, e.g. in PostingList PostingDB::get(const QByteArray& term), we have<br>
> tons of bugs about random crashs afterwards: <a href="https://bugs.kde.org/show_bug.cgi?id=367480" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.<wbr>cgi?id=367480</a><br>
><br>
> 4) 32-bit systems supported at all? ATM, after 1GB of indexing, that was it, no more baloo or any other application<br>
> calling any of the accessors of e.g. Query (if you have bad luck).<br>
<br>
</span>If you have the time to fix those things you've listed above, awesome<br>
- I'd love to look at the RRs. Lessens my workload.<br>
<br>
Otherwise I'll look at this on the weekends when I have no sysadmin<br>
things to do.<br>
<span class=""><br>
><br>
>><br>
>>> Beside that, could we get some <a href="mailto:baloo-bugs@kde.org">baloo-bugs@kde.org</a> list as default assignee<br>
>>> for all baloo bugs instead of "one" person?<br>
>><br>
>> If we're going to do it this way, why not just make it the default<br>
>> frameworks mailing list, or the frameworks bugs list if there is one?<br>
> I am not sure, if that will make people happy ;=)<br>
<br>
</span>Let's get other people involved, too ;-)<br>
<br>
Thanks,<br>
Boudhayan<br>
</blockquote></div><br></div>