Registered Member
|
KDE leaking into ~/.xsession-errors is a known bug. Mine was 58 GB at one stage… There is a workaround in the link, although it's been fairly well behaved for me in the last few months (since moving from Ubuntu to Arch).
|
Registered Member
|
It looks like it's using 100% of a core again. I left it for an hour or so, then got annoyed and ran these commands. It's been going for another hour… |
Registered Member
|
New installation: Baloo takes all RAM after a minute and crashes Plasma. Guess there are enough bug reports around .
|
Registered Member
|
I'm not sure if this is related, but when I boot, I get this message, asking for root permission. When I hover over the link, it says "Click to edit org.kde.baloo.filewatch.raiselimit". I've only noticed this in the last week or so, probably since the upgrade from baloo 5.9.2-1 -> 5.13.0-2 on 19 August. This is also a similar time to when I noticed the 100% CPU bug again.
EDIT: I attempted to boot without giving it root permission; I'm not really sure why it should need it. However, the window just kept popping up again. |
Registered Member
|
Try this. https://wiki.archlinux.org/index.php/KD ... atch_limit It's possible this might fix your 100% CPU usage issue as well. It could just be that baloo or some other program isn't able to handle hitting the limit in a graceful fashion. |
Registered Member
|
Thanks for the suggestion. Unfortunately, after a reboot, I still got the popup. OTOH, the 100% CPU thing seems to have disappeared by itself. ==EDIT== I added my home directory to the list of directories for baloo to ignore. That stopped the popup on reboot! |
Registered Member
|
It is unacceptable that *TWO* years after this report that the problem persists. There is no excuse. It should not be necessary for me to go googling around to figure out how to fix up the baloo database or disable the stinky thing. If you can't fix it, then GET RID OF THE DAMN THING. Thank you.
|
Registered Member
|
i deleted ~/.xSesion whatever is . then fixed problem
|
Registered Member
|
Having this same problem.
Running Kubuntu 16.04 LTS 64bit. After I click to do something I'm normally hit with about 15s of system lag. baloo_file_extractor is constantly running. Do I need it? Can I remove it or stop it permanently? I don't need to search for files if indexing is all it does. |
Registered Member
|
Can you check the output of the following command, and if it is updated when you download e.g. a new pdf file from the internet?
Not entirely sure, but I think it is possible to disable baloo_file_extractor specifically by running
Last edited by ozone on Sun Feb 11, 2018 9:22 pm, edited 1 time in total.
|
Registered Member
|
thanks for the advice! it helped to add
|
Registered Member
|
This is a tough problem
On Fedora 27 with:
I have two baloo_file_extractor instances running. Each is allocating 100% of a core. One instance is for the currently logged-in user, one is for another user (not currently logged in). Both seem to be going nowhere (maybe they are actually mining bitcoin?). Watching the script
to check which files are held open shows an immutable list, actually identical for both instances:
Querying baloo via qdbus yields nothing:
Nothing peculiar in the SELinux audit log with
Just taking a short look with gdb, I'm no longer used to this.. installing debuginfo:
Attach to the process:
We get:
Both instances are in Baloo::DocumentUrlDB::get(). Are they mutually deadlocking? Are they looping in there? Source from https://api.kde.org/frameworks-api/fram ... ource.html shows a suspicious loop
...just a possibility. |
Registered Member
|
Install the debuginfo for libKF5BalooEngine:
According to your backtrace, it is currently inside Baloo::DocumentUrlDB::get On the gdb prompt, do:
Now, see while it (apparently) loops:
You can repeat 2. and 3. to watch if it shows any progress. And, when you have gathered the information, please report a bug at https://bugs.kde.org, Product frameworks-baloo, Component engine. |
Registered Member
|
Thanks bruns.
Still wrangling the gdb (baloo again treading water, but the stack trace is different) You seem to have opened https://phabricator.kde.org/D12335 - "Avoid infinite loops when fetching the URL from DocumentUrlDB". So my baloo is currently in deep swampland again:
and seems to be forever looping in
I have not really found an original source repo for Qt, thus code from apt-browse-org https://www.apt-browse.org/browse/ubuntu/trusty/main/i386/qtbase5-dev/5.2.1+dfsg-1ubuntu14/file/usr/include/qt5/QtCore/qstringbuilder.h At 340 we find an inlined
I don't know what's going on in there, the first sensible stack frame moving up is
The above line can be found in https://api.kde.org/frameworks-api/frameworks-apidocs/frameworks/baloo/html/documenturldb_8cpp_source.html (however at line 154, how do I into obtaining the correct source file, is it time to embed URLs to github into debug information yet?) So, here we seem to try to concatenate three things using operator '+'....
'/' is a char "p" is marked 'auto' and thus apparently a "IdFilenameDB::FilePath" where the "FilePath" is a struct wrapping a "QByteArray" according to https://api.kde.org/frameworks-api/backup/frameworks/baloo/html/idfilenamedb_8h_source.html. So "p.name" is a "QByteArray". And trying to concatenate that char and those two "QByteArray" seems to result in non-termination. Weird. |
Registered Member
|
You are apparently using baloo from KF5.44, which does not contain the fix.
Its the responsibility of distributions to either provide current versions of the packages, or at least cherry-pick bugfixes from upstream. |
Registered users: bartoloni, Bing [Bot], Google [Bot], Yahoo [Bot]