[kde-linux] Konqueror and Dolphin using 100% CPU

[Duncan]

Dale posted on Wed, 22 Feb 2012 21:47:18 -0600 as excerpted:

> I am mostly curious right now.  I used to use Konqueror as my file
> manager.  I noticed when I left it idle for a bit, it would start using
> 100% of one of my cores.  It has been doing this for a while so I can't
> say which upgrade it started on.  Anyway, when it started doing this, I
> switched to Dolphin for my manager.  I thought maybe it would be more up
> to date or something.  Anyway, it does the same thing.
> 
> When I use top, or htop, to show what is using so much CPU, it is
> kdeinit4 at the beginning but either Konqueror or Dolphin as the actual
> process running.  I'm not sure what triggers this issue right now.  I
> usually use it to watch videos or something.  It doesn't do it in a way
> that is reproducible yet but I am trying to figure out what triggers it.
>  When I close the file manager, the CPUs go back to normal.
> 
> I'm using Platform Version 4.8.0 but it was doing it on the last version
> too.
> 
> Has anyone else seen this?  If so, any fix yet?

I'm not sure if this is what you're seeing, but see if it fits...

If previews are enabled in konqueror/dolphin, and you're in a directory 
with a large number of images or even more so videos, they will use a lot 
of CPU trying to generate thumbnails for all those image-files.  Videos 
take more cpu and will I believe only be thumbnailed if you have the 
appropriate thumbnailers installed (mplayerthumbs and/or another similar 
app the name of which IDR ATM).

Once all the thumbnails are generated, there will be a burst of cpu on 
directory entry as it checks the hashes and loads the corresponding 
thumbnails, but it will die down MUCH sooner.  But until they're all 
generated, there will be a pause to let the pre-generated thumbs load, 
then if there's no activity, the background thumbnailing process will 
startup again.  If it doesn't finish before you close the window or go to 
a different dir, it will start up again the next time where it left off, 
so in a few-hundred-video-dir, it might get maybe 3-5 videos each time 
during normal usage if you're in the dir only a little bit, and thus take 
maybe a hundred visits to the dir before all the videos are thumbnailed.

As such, the pattern is much different before all the videos are indexed 
(initial burst, wait, pick up again) compared to after (longer initial 
burst as there's more thumbs to load, without the pickup again).

A possible snag in this is if the various components (mplayer, the 
thumbnailer, dolphin/konqueror, various kde and other libs) get out of 
sync with each other.  That could stop the activity until they're back in 
sync, or make it much worse as the thumbnailers repeatedly try to load, 
and crash, without actually generating any new thumbnails.

As both you and I are gentooers, a revdep-rebuild can help here, but I'm 
not sure it catches /all/ such issues.  (It catches most library out-of-
syncs, but I'm not sure it catches plugins, which often only load on 
specific actions and won't normally cause problems if they're not there, 
like fully depended libs will.  And there's multiple ways to load a 
library and I'm not sure revdep-rebuild catches all the obscure ones.)  I 
do know that revdep-rebuild sometimes reports all clean, here, but still, 
something doesn't work for a time, but then when all the updates happen 
to be built in the correct order again, suddenly things work again.  
There's two cases I've seen where this seems to happen, the thumbnailers, 
and the gnash/lightspark flash replacement plugins.  I simply don't have 
the technical understanding to really grasp /why/, tho I believe I sort 
of understand a bit of it (the different ways to load libs, and the case 
of libs vs plugins, both of which are "shared objects", aka *.so.*).


The kdeinit4 thing is a trick kde uses to launch faster and be a bit more 
efficient with resource usage.  Instead of each kde infrastructure app 
loading all its resources separately, kdeinit4 is used to load common 
resources once for several apps, thus shortening the initial launch and 
reducing memory usage.  The following is rather simplified, but AFAIK, 
it's reasonably accurate as the high level explanation it's intended to 
be:

In Linux as originally designed, "shared object" libraries can load once 
and be shared by as many apps as need them, but that was back when 
libraries loaded at predictable locations.  Now days, various archs 
(including amd64/x86_64) mandate and some distros use even on x86, 
"randomized memory space object relocation", for security and other 
reasons.  (Security-wise, if a function's location can be predicted, it's 
far easier to exploit a potential vulnerability to allow an attacker to 
take over the machine.)  Also, even when shared object libs try to load 
at specific locations, they can only do so if other libs aren't already 
at that location, in which case they must be loaded elsewhere anyway.

Unfortunately, libraries loaded at different locations in different apps 
take longer to initialize and don't as effectively share memory.  Thus, 
kdeinit4, which allows the various kde4 "core" apps to all load together, 
more effectively sharing resources and loading faster.  Address space is 
still randomized at load time for these apps so security isn't thrown out 
the window, but it's randomized once for all of them together instead of 
once for each one.

If one of the apps crashes, it can be rerun by itself, but of course the 
benefits of the common init are lost that way.  Since it's just one app 
being reloaded, init time isn't as big an issue, but other things being 
equal, memory usage will be slightly higher.  And AFAIK, kdeinit4 can't 
be used to just rerun the single app anyway.  If a full rerun is desired, 
you quit kde back to the *DM login or text console (depending on how you 
launched it in the first place, I always use a text console launch and 
never a *DM graphical login, but others prefer their graphical login), 
and relaunch.

That should address the kdeinit4 <app> angle. =:^)


Finally, FWIW, for file browsing, in kde4, konqueror loads the dolphin 
kpart.  The wrapper around the kpart is different between dolphin and 
konqueror, but it's the same dolphin file browser kpart underneath.  So 
it's not surprising that behavior and bugs seen in one are often seen in 
the other, as well.  It simply depends on whether that aspect is part of 
the wrapper UI, or an underlying behavior of the kpart.


> Also, I had to disable previews on my Desktop.  When I would hover the
> mouse over a icon, it would kill the kicker at the bottom and my
> wallpaper.  It would kill processes to the point that I could not logout
> normally.  I could not right click on the desktop and since the kicker
> was gone, no K menu either.  I'm not sure if these could be related and
> most likely are not but it is a odd thing.  On this matter, I have mine
> set to show the icons on my desktop.  I think it is called "folder
> view."

FWIW, "kicker" was the kde3 panel app (kdesktop was separate).  In kde4, 
the entire desktop and panels are "plasma" (plasma-desktop normally, 
plasma-netbook's used in some cases).  KDE /does/ try to respawn plasma 
if it crashes, but it doesn't always catch it, and of course if the 
problem is bad enough it could crash repeatedly.

However, while in kde4 the desktop and panels are combined, krunner is 
deliberately kept as a separate process even tho it uses many of the same 
libs, precisely to keep either krunner OR plasma-desktop usable if the 
other one crashes.

Thus, even with plasma crashed, you /should/ be able to still use the 
krunner hotkey (alt-F2 by default, IIRC) to invoke it, and can type in 
whatever you'd launch that way, including rerunning plasma-desktop from 
krunner.

If you have a konsole window open, you can of course run either one 
(plasma-desktop, krunner) from there as well.  And of course you can run 
konsole from either plasma or krunner.

Similarly, the hotkey mechanism appears to be separate.  (I've not 
actually figured out what app is responsible for it as I no longer see 
the khotkeys app running that kde3 had, but I've had both krunner and 
plasma crash on me at various times, and the hotkeys still appear to 
respond with either one down, so it's gotta be separate from either.)  
Thus, it's possible to configure hotkey launchers for plasma-desktop, 
krunner, kwin, and konsole, so you can always get them back as long as 
the hotkeys component is still running, with just a press of the 
appropriate hotkey combination.


FWIW (tl;dr: description of my setup follows)...

Here, to replace the missing multikey hotkey functionality in kde4 that 
used to work so well in kde3 (FWIW, the relevant kde bug says it's due to 
a qt4 defect, apparently unfixable in qt4 as it's an architecture 
assumption, but I've read that it's already fixed in qt5), I've setup a 
couple scripts and a whole set of launcher-config files, that allow a 
three-key launch of pretty much anything I use regularly, including 
launchers for the apps listed above, should they crash.  The first key is 
a khotkey that invokes my launcher with a list of categories (config=c, 
filesystem=f, games=g, net=n, raid=r, terms=t, X=x, etc) and associated 
hotkey, the second choses a category and invokes the launcher again with 
a list of the apps/hotkeys for that category (for net, b=bank (browser 
loading the bank's login page), z=bugZilla-gentoo (browser URL), F=firefox 
(general launch, blank page), m=mail (claws-mail, mail instance), f=feeds 
(claws-mail, feeds instance), n=news (pan, nntp news client), etc).

So if I want to launch a konsole window, it's simply <launcher-key>,t,t 
(first t, terminals category, second, general terminal window), to launch 
konsole directly sudoing to my admin user, it's <launcher>,t,z, to 
relaunch kwin with the --replace parameter if it crashes, it's 
<launcher>,x,w (x=X-category, w=kWin), to launch kpat it's <launcher>,g,p 
(games, kPat), getting a browser open to the bank login page is 
<launcher>,n,b (net, bank), to open kde settings s <launcher>,c,s 
(config, kdeSettings), to relaunch a crashed krunner it's <launcher>,c,r 
(config, kRunner), to activate and mount my media raid it's <launcher>r,m 
(raid, media)... etc.

Just three keys to launch anything on the system I use enough to have 
bothered setting up an entry for it in the launcher config! =:^)  And 
it's all nicely categorized and mnemonically arranged so I normally 
remember it without prompts, but the category and individual apps lists 
for that category popup, just in case. =:^)

And as can be seen from the examples, that includes restart launchers for 
kwin, krunner, plasma-desktop, etc, along with such things as config 
resets for mouse accel (sometimes that resets and the mouse moves like 
molasses until I reset the accel), triggers to immediately turn off the 
monitors, or conversely, to keep them on so they don't blank on their own 
after X minutes of inactivity, triggers to run a script to assemble 
various auxiliary md/raids and mount the filesystems they contain, 
triggers to load the browser with specific pages... all the random misc 
one-shot and app launcher stuff I might want to do on the system.

Of course, if there's an app I'm not familiar with or simply don't use 
enough to have created a 3-key launcher, I can use the usual launch 
methods, kickoff menu, typing it in krunner, launching konsole and using 
tab-complete to launch it from there, etc, that an ordinary user might 
use, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman