I just compiled KDE SC 4.10 beta1 (ell actually it is a bit newer since I compiled from git) and soon after I startup KDE workspace "nepomukservicestub nepomukfilewatch" process goes crazy and starts using 100% of CPU and increasing memory usage. When activity stops the memory usage is at about 2.5 GiB (laptop has about 4 GiB of memory installed). Indexing is enabled for all files, except Source Code and removable media is ignored. Virtusos memory is set to 50 MiB. Reproducable: always Steps to reproduce: 1) just login to KDE Plasma 4.10 desktop 2) wait for a few minutes Actual result: nepomukservicestub nepomukfilewatch uses a lot of memory Expected: It should not use much of memory. About 100 MiB max I guess.
I also stopped nepomukfilewatch and restarted it from terminal and this is what it outputs $ nepomukservicestub nepomukfilewatch nepomukfilewatch(11959)/nepomuk (library) Nepomuk2::ResourceManagerPrivate::_k_storageServiceInitialized: Nepomuk Storage service up and initialized. nepomukfilewatch(11959)/nepomuk (library) {anonymous}::GlobalModelContainer::init: Connecting to local socket "/tmp/ksocket-jlp/nepomuk-socket" nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::FileWatch::watchFolder: "/home/jlp" nepomukfilewatch(11959)/nepomuk (filewatch service) KInotify::addWatch: "/home/jlp" nepomukfilewatch(11959)/nepomuk (filewatch service) KInotify::Private::open: nepomukfilewatch(11959)/nepomuk (filewatch service) KInotify::Private::open: Successfully opened connection to inotify: 14 nepomukfilewatch(11959) Nepomuk2::RemovableMediaCache::createCacheEntry: Usable "/org/freedesktop/UDisks/devices/sdb1" nepomukfilewatch(11959) Nepomuk2::RemovableMediaCache::slotAccessibilityChanged: true "/org/freedesktop/UDisks/devices/sdb1" nepomukfilewatch(11959) Nepomuk2::RemovableMediaCache::slotAccessibilityChanged: "/org/freedesktop/UDisks/devices/sdb1" accessible at "/media/Prevajanje" with identifier "filex://167bec17-e2b1-4afa-bec2-3258682648b2" nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Searching for invalid local file entries nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::FileWatch::slotDeviceMounted: Device configured to not be indexed. nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::FileWatch::slotDeviceMounted: Installing watch for removable storage at mount point "/media/Prevajanje" nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::FileWatch::watchFolder: "/media/Prevajanje" nepomukfilewatch(11959)/nepomuk (filewatch service) KInotify::addWatch: "/media/Prevajanje" nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Done searching for invalid local file entries nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Searching for invalid local file entries nepomukfilewatch(11959)/nepomuk (filewatch service) KInotify::Private::addWatchNoCheck: Failed to create watch for "/media/Prevajanje/lost+found" nepomukfilewatch(11959)/nepomuk (filewatch service) Nepomuk2::InvalidFileResourceCleaner::run: Done searching for invalid local file entries
I have a fairly good idea as to why this is happening. However a massif report would be nice as well. $ qdbus org.kde.nepomuk.services.nepomukfilewatch /servicecontrol shutdown $ valgrind --tool='massif' nepomukservicestub "nepomukfilewatch"
Created attachment 75519 [details] Compressed massif output
If you want, you can test the fix - https://git.reviewboard.kde.org/r/107529/ Though I'm confident that this fixes it.
If I didn't do anything wring while applying the diff then I'm afraid it doesn't help. Running on laptop now and KSysGuard says the memory usage is now 2.7 GiB and the laptop has become almost completely unresponsive but the HDD LED is still on.
Created attachment 75567 [details] New massif output And this is the new output from massif, if it helps in any way.
I'm trying to diagnose it, but till then would it help if you could do a git bisect and try to find the commit responsible. It would help a lot.
I've recompiled all Jde from 4.10 branch yesterday and it looks like the problem is gone now. I guess I can close the bug now.