https://bugs.kde.org/show_bug.cgi?id=434926
--- Comment #12 from [email protected] --- (In reply to nyanpasu64 from comment #11) > ## Do other processes write to the database? (unknown) My feeling, no. It's just baloo_file and locking is absolutely critical. I'm not so sure how/when baloo_file recognises when the index is being "read" and therefore has to append instead of update however it's clear that this is happening is you look at Bug 437754 (where you see that a "balooctl status", which seems to enumerate files to be indexed, means that updates are "appends" and the index grows dramatically). > ... I don't know who wrote the corrupted file I know there was a flood of "corruption" reports (Bug 389848). This issue was found but the fix left the index corrupt and it became normal to recommend purging and rebuilding the index (Bug 431664). Yes, still quite a while ago and the number of these reports is dropping away but it did resurface when people upgraded from Debian 10 to 11 (which was only the end of last year) Would writing the "bad pointer" be noticable in the code? Might it be possible to add asserts? > The crash happens in UnindexedFileIndexer::run() Interesting in that baloo "batches up" its content indexing work (where it analyses 40 files at a time and writes the results to the index) however it deals with the initial scan of files it needs to index in a single tranche; give it a hundred thousand files it needs to index, it will collect the information for all of them and write the results to the index in one go. This can be pretty horrible (see Bug 394750) No reason that this is a cause but it is a behaviour that might raise the stakes... > ... evaluate the performance differences One of the joys of baloo is it's amazing speed, that you can type a search string and see the results refine themselves on screen. -- You are receiving this mail because: You are watching all bug changes.
