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

[Dale]

Duncan wrote:
> 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.


I been messing with this for a bit.  I just plain old disabled the
preview stuff for everything including the desktop icons.  The desktop
setting was easy but I can't get dolphin to retain the settings after a
restart.  If I close then restart dolphin, everything resets to defaults
and plain ignores my settings.

So, one problem has uncovered another.  How do I FORCE dolphin to retain
my settings?  Do I need a bolt, nut and a good set of wrenches?  I got
some.  Grade 8 bolts and Craftsman 1/2 inch drive sockets.  I also have
a 6 foot cheater pipe and a pull handle too.  I need this thing to
tighten up a bit here.  lol


> 
> 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.*).
> 

My usual upgrade path is, eix-sync && emerge -uvaDN world then
--depclean then revdep-rebuild -i.  I tend to keep my system saner than
me.  o_O


> 
> 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.
> 
> 

Is KDE taking after winders?  ROFL  I noticed the other day that it now
shows dolphin on the front.  Maybe it was the way I was running the
command.  < shrugs >



>> 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.
> 


I use the same stuff over and over so I just save the session and it
opens everything when I login.  It even launches Seamonkey now.  It
didn't use to do that.  It seemed to launch everything KDE related but
not apps outside of KDE stuff.  Glad that is fixed.

I did just notice something.  In dolphin, there is a PREVIEW button
right there in my face.  It's right below the menu button thingy.   I
clicked on it.  Maybe that will help.  Of course, I have to remember to
click it every time I open dolphin tho since it won't save my settings.
 This is a lot easier for me on Konqueror.  It generally "just works"
for me.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"