It's difficult for me to really report this issue as a singular crash within Baloo. After suffering so many random crashes that are unrecoverable unless the index is deleted and rebuilt from scratch, I have decided to report this as a singular bug.

Baloo crashes often, for a variety of reasons, and has very poor error handling.

The primary issue is *not* the mere fact that Baloo crashes. Almost all programs are bound to crash from time to time. The issue is, Baloo fails silently and seems to have virtually no recovery mechanism whatsoever.

On 5.47.0 about two weeks ago, my database at ~/.local/share/baloo/index became corrupt, which resulted in baloo leaking memory until my 8 GB of RAM were all eaten up, and the kernel had to kill it with OOM killer.

On 5.48.0, everything was working swimmingly for about a week and a half. Then, I printed an email from Seamonkey Mail to PDF. Baloo's attempt to index this file inexplicably caused Baloo to crash, and my index again became corrupt.

This time, thankfully, there is no memory leak, but even after logging out, killing baloo_file (which had to be done manually since the process was still running after logout [see, eg, https://bugs.kde.org/show_bug.cgi?id=391253]), removing ~/.local/share/baloo/index-lock, removing the offending file, and restarting Plasma5, baloo has now become extremely crashy and unstable.

Now, introducing any file into $HOME causes a crash. Even running "touch foo" in my $HOME causes a crash.

At any rate, these issues sound very, very difficult to debug. Just pointing your browser to https://bugs.kde.org/buglist.cgi?quicksearch=baloo is extremely overwhelming. Rather than trying to bandage these bugs one by one, would it not make more sense to build more user-friendly error handling into Baloo? Is it absolutely impossible to repair a baloo database without doing a full rebuild? Perhaps upon crash due to a corrupt DB, baloo could auto-repair itself?