https://bugs.kde.org/show_bug.cgi?id=332421
Brendon Higgins <bren...@quantumfurball.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bren...@quantumfurball.net
--- Comment #44 from Brendon Higgins <bren...@quantumfurball.net> ---
Does the "avoid indexing large text files" hack in extractor/app.cpp (which in
master has a 10 MB limit) still work if the text file starts small but happens
to rapidly grow large from another process at the same time it is being
indexed? I had a simulation running that appended (a lot of) numeric data to an
initially empty text file, and by my observation it seemed like baloo blew up
on it. I'm unfamiliar with baloo's code, but taking a glance at it
(particularly app.cpp) suggests to me that this scenario might be possible.
On a separate machine, and maybe a separate issue, I noticed
baloo_file_extractor running for a long time with significant RAM usage (>2GB)
that did not decline until it had apparently finished indexing a few thousand
files that I had recently changed. Why would it need to hold so much RAM as it
goes from one file to the next? In the source I notice a database handler that
seems to persist for the entire batch (this is even marked with a FIXME). Could
there perhaps be a leak in that?
--
You are receiving this mail because:
You are watching all bug changes.
