Description of problem: When I first login to my KDE4 system, Konqueror browses directories very quickly. But after a little system use, it will slow to a crawl, taking 10 sec to show the home directory, and 1:20 to display a directory with 600 files in it. Once this starts, Dolphin exhibits the same behavior. During this delay, top shows konqueror only taking 1-2% of CPU. Trying to close konqueror during the delay will bring up the 'not responding' dialog. An 'ls' of the same dir is instant. I attempted a 'strace konqueror --profile filemanagement' to see what was going on. The last few lines of the trace: stat("/var/tmp/kdecache-bdaniels/kpc/kde-icon-cache.data", {st_mode=S_IFREG|0664, st_size=16240640, ...}) = 0 stat("/var/tmp/kdecache-bdaniels/kpc/kde-icon-cache.data", {st_mode=S_IFREG|0664, st_size=16240640, ...}) = 0 stat("/var/tmp/kdecache-bdaniels/kpc/kde-icon-cache.data", {st_mode=S_IFREG|0664, st_size=16240640, ...}) = 0 select(Aborted $ Closing and restarting konqueror does not fix the problem. Logging out and back in usually does. Sometimes it will 'fix itself' during a session, then go bad again. The same hardware did not exhibit this problem with F8/KDE3.
Created attachment 335261 [details] strace crashing when tracing konqueror hang
The problem is still present after recent updates. I attempted a strace -p as root of the running user process, and saw a ton of the following messages during the hang: read(8, 0x1c96ce4, 4096) = -1 EAGAIN (Resource temporarily unavailable) I attempted more traces to try and track down what file was involved, but now just moving the mouse pointer over the konqueror window causes strace to exit with a *** glibc detected *** strace: malloc(): memory corruption (fast): 0x0000000000c10610 *** I have attached the trace attempt file. The filesystem of /home is ext4, if that has any relevance.
Thank you for the bug report. This issue needs to be addressed by the upstream developers. Please submit a report at http://bugs.kde.org. You are requested to add the bugzilla link here for tracking purposes. Please make sure the bug isn't already in the upstream bug tracker before filing it.
After more digging, found that disabling Nepomuk/Strigi made the bug go away. May be related to: https://bugs.kde.org/show_bug.cgi?id=172176 and linked there.
Yes, looks like it, we'll continue tracking this upstream.
KDE devs responded as follows: "it's a Redland issue, not a Java issue, we still don't have Sesame2 in Fedora because packaging it according to Fedora's guidelines is months of work (the package in kde-redhat unstable uses the binary JARs and is thus not acceptable in Fedora)." I've been working around it by disabling Nepomuk. It sounds like no fix is intended upstream until/unless Sesame2 is in Fedora.
Sad state of affairs, indeed. Let's look forward to kde-4.3 and virtuoso I guess.