After installing KDE 4.10 rc1 (4.9.95), I started seeing nepomukservices using 100% cpu. An strace shows what appears to be nepomuk being stuck in a directory with recursive links (xmlrpc-c/src/cpp/srcdir -> xmlrpc-c). strace output will be attached. If you look for a specific file, for example libxmlrpc_util.so, and search for it, you'll find it several times, each time deeper down in the dir hierarchy. It's also worth noting that this directory hierarchy is in a directory that should have been excluded from indexing (as far as I know, guess there might be a link somewhere from an indexed directory - should nepomuk follow links outside indexed dirs?). Reproducible: Always Steps to Reproduce: 1. Create a directory hierarchy with at least one link pointing back to the base dir (2. Make sure the newly created directory hierarchy is in the selected list of dirs to index) 3. Run nepomuk with file indexing enabled. Actual Results: Nepomuk is stuck at 100% cpu usage and appears to make no progress Expected Results: Close to no cpu usage, and progress while indexing.
Created attachment 75976 [details] Strace output from nepomukservices while being stuck at 100% cpu usage
I'm sorry. I'm not sure how to read the strace. Could you please provide the following information? 1. Full application name - nepomukservicestub <pluginName> 2. GDB Backtrace? You can obtain the gdb backtrace as follows - $ ps aux | grep nepomuk # Get the pid of that process $ gdb --pid <pid> $ thread apply all backtrace
Created attachment 75977 [details] GDB backtrace The offending process is: /usr/bin/nepomukservicestub nepomukfilewatch The backtrace was taken after verifying with the strace output that it is indeed stuck at the same directory hierarchy.
Confirmed. Another developer has also reported the same bug via IRC. I'll try to have it fixed before RC2.
Git commit 3daabb6407383b0620b8c6db9973fc9be8f0a6fd by Vishesh Handa. Committed on 30/12/2012 at 16:11. Pushed by vhanda into branch 'KDE/4.10'. FileWatch: Do not add watches for system links Following system links can lead to various infinite cycles, which is something we do not ever want. I'm not sure if there is any advantage gained by adding watches to them? REVIEW: 108025 M +3 -2 services/filewatch/kinotify.cpp M +0 -11 services/filewatch/nepomukfilewatch.cpp http://commits.kde.org/nepomuk-core/3daabb6407383b0620b8c6db9973fc9be8f0a6fd
*** Bug 312497 has been marked as a duplicate of this bug. ***
Works as expected in 4.10 rc2. Thanks!
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Development has moved to Baloo, please try again using the latest version and applications, and submit a new ticket for frameworks-baloo if you still have an issue. Thank you!