plasma-desktop (KDE factory) acting up?

[Duncan]

Alex Schuster posted on Fri, 29 Oct 2010 21:12:31 +0200 as excerpted:

> I'm also having plasma trouble. Plasmoids tend to not remember their
> position and sizes, expecially folder plasmoids, but that's a minor
> problem. What causes much more trouble is that my activities get mixed
> up. I have one activity per desktop, and suddenly most desktops have the
> wrong activity. This has happened for 3-4 times now.

Yeah, that sounds like the same general issue..

One thing I understand from following planet-kde for awhile (I quit as 
there wasn't so much stuff I was /really/ interested in and I have way 
more feeds in akregator than I can keep up with as it is, and it was one 
of the easiest for me to drop since I'm /not/ so interested in much of the 
content), as well as following quite well the general FLOSS community 
news, is that...

Plasma is still *VERY* *MUCH* a work in extremely active development.  
Actually, while I understand reasonably well where they're trying to take 
it, and why (based on what asegio etc have written), if you look back at 
early kde4, the plasma interface was the big part of caused 4.0-4.2 to be 
panned as badly as they were -- the rest of kde was at least /reasonably/ 
stable, but the desktop, panel and launcher services plasma provides are 
EXTREMELY critical to a good GUI experience, and plasma simply wasn't yet 
even beta quality with 4.2, let alone functional, polished and stable 
enough to be rated the release quality that they were claiming as of 4.2 
for kde4 in general.  As a result, the unstable plasma ended up dragging 
the reputation of all of kde4 thru the mud.  Had it been anything /other/ 
than plasma, it wouldn't have been so bad, but as I said, the services 
plasma provides are by very definition, absolutely critical to a 
reasonable desktop experience.

Anyway...  With 4.4 things were finally looking reasonably functional and 
non-crashy on the plasma front, enough that with it, I finally considered 
kde4 "release candidate" quality -- generally good enough to release, but 
with a few niggling bugs that at least the engineering side would normally 
want to get rid of before release.

In that regard, 4.5 did finally make what I'd consider release quality -- 
what really /should/ have been 4.0.  But, as with any .0 release, there's 
still improvements to be made, even if it's finally release quality...

Which brings us back to the topic at hand.  As you likely recall, the 
activity interface in 4.4 and previous was the zooming interface.  But 
that absolutely went over like a lead balloon in much of the community, 
and the plasma folks ended up changing it.  As it happens (or not, IMO 
it's causatively connected), that's the same version that I finally 
considered release-grade (it's causatively connected in that that change 
was part of the /reason/ it finally felt to me like release grade, the 
interface finally worked reasonably).

But, as with any such changes made that late in the cycle, between (should-
have-been) rc and final .0 release, the initial release version is often a 
big buggy, and ultimately, a .1 release (or SP1) is needed to bring the 
implementation in line with the vision for it.

Well, using kde4's actual versioning, that .1 release will be 4.6... and 
based on the kde4 history so far, I can quite confidently predict that it 
should be MARKEDLY better than 4.5, even if I'm /not/ following kde-planet 
and therefore asegio's blog (in particular for plasma) as closely as I was.

What I think happened, then, is that they rather obviously screwed 
something up in the switch from the activity zooming to the activity 
scrolling interface.  Least-wise, I don't recall this complaint appearing 
anywhere, and I certainly never experienced the issue, with the zooming 
interface, which by 4.4 was reasonably mature, stable and functional, even 
if few actually found it as natural to work with as 4.5's activity 
browsing interface.

BTW, I don't use the activity per desktop option, but IIRC it only 
appeared in 4.4 or 4.5 as well, so its implementation probably isn't quite 
stable yet, either.  Also, while they've added it by popular demand, it 
doesn't fit well the activity concept the plasma devs have, so they don't 
tend to use it themselves, and it likely gets rather less testing than 
desktop-unlocked activities as a result.  That might be part of what 
you're seeing if you're using the option.

> I [started from a clean config] some months ago, hoping that those many,
> many bugs are the result of some configs that got corrupted along the
> updates from KDE 4.2 to 4.3, 4.4 and 4.5. Some things were fixed indeed,
? but most problems stayed. This took half a day of work, so I'd hate to
> do this again whenever a KDE problem arises.

[mode=aol] As I made plain in the upstream posts, me too! [/mode]

> Maybe my setup is just over-complicated? When I look at screenshots of
> people using KDE4, they often only have two desktops. Well, I have eight
> desktops and activities, in case someone is interested, there are some
> screnshots here:
> http://www.wonkology.org/comp/desktop/2010-06-19/
> 
> The current setup is a little different, but not much.

Wow!  While your customization is rather different than mine, it's 
certainly as customized. OTOH, you mention below that you're a Gentoo user 
too, and Gentoo's known for the customization options it offers, so that 
isn't /so/ surprising, I guess.  =:^)

FWIW, it's rather old (4.2 era, when I was switching from kde3 to kde4 and 
still had elements of both installed and running, together), but I still 
use a generally similar arrangement to the one in the screen shot here:

http://members.cox.net/pu61ic.1inux.dunc4n/

I still have dual monitors in stacked config, tho I'm now running slightly 
shorter ones, standard US 1080p HD, so the overall resolution is 1920x2160.

Likely as a result of the additional screen space the dual monitors gives 
me, I don't actually use as many desktops as I might.  I only use three, 
and only have a single "activity"... tho due to the way plasma worked 
pre-4.5 each monitor formerly displayed a different "activity", but the 
two formed a single desktop.  4.5 has changed that somewhat and it's clear 
that the intent is to have the whole desktop be the activity, even if each 
monitor has its own separately configured background, but again, it's 
clearly a WIP (work in progress), which sort of works, but I expect will 
be MUCH more polished and functional in 4.6 (what arguably should have 
been kde4's .1 release, by traditional measures).

I still have the big panel at the top, now all plasma, of course, with the 
system activity graphs that were provided in the screenshot by kicker's 
ksysguard applet now provided by the yasp-scripted (yasp=yet-another-
systemmonitor-plasmoid) plasmoid off of kdelook.org, since there appears 
to be no proper ksysguard plasmoid to replace kde3's kicker applet.  In 
addition to the several yasp-scripted sysmon plasmoid instances (including 
one tailing syslog), this panel also includes the systray.

Instead of the full-width bottom panel, since knewsticker was discontinued 
(I still miss it) and I now use akregator for my feeds, I've only a very 
short bottom-left panel set to auto-hide, with kickoff (which I don't use 
much as all my regular apps are hotkey-launched) and a classic menu with 
bookmarks and kcontrol menus, as the only plasmoids.

I have a digital clock displayed in one of my yasp-scripted instances, but 
on the desktop, top monitor, I have a big analog clock plasmoid as well, 
plus a narrow folderview to the left, a couple quick-access plasmoids 
(kdelook), and yawp.  The top monitor is still "auxiliary/overflow" usage, 
since the usable area is smaller due to the sysmon panel taking up the top 
third.  As a result, the desktop is usually exposed enough so I can access 
it without too much trouble, and the plasmoids I have there are thus 
reasonably utilitarian (mainly filesystem access) in nature.  I have the 
over-desktop mouse-scroll function set to switch desktops, which is quite 
convenient, since as I mentioned, the top monitor desktop is generally at 
least partially exposed.

ON the desktop, bottom monitor, I have only a single plasmoid, the comic-
strip plasmoid you too mention.  This is because the bottom monitor is my 
"working" monitor, and I tend to have it covered by windows most of the 
time.  Since few comics update more frequently than daily, once I've seen 
my comics for the day, I'm done, so covering it isn't a big deal.

Window-placement-wise, I REALLY like the drag-to-side-half-maximize (to 
monitor, so it stays in the active monitor not over both) feature that 
appeared in 4.4 and use it a LOT!  (OTOH, on a dual-monitor stacked config, 
the drag-to-top-to-maximize functionality is annoying, since it triggers 
when dragging to the top of the BOTTOM screen too, and that's the MIDDLE 
of the desktop.  So that option's turned off.)  My normal config (with 
kiwn's customized window-rules applied to help) runs both konsole and 
konqueror (my default browser, tho I use firefox as well) half-maximized, 
so I get two instances side-by-side.

Kmail, akregator and pan (USENET/news client, about the only gtk app I run 
other than firefox) run almost-maximized in the bottom monitor, with pan 
getting its own dedicated "news" desktop.  (As I mentioned above, I only 
run three desktops, pan on one, and two others so I can have whatever 
project open on one and still have the other for a second project or as a 
free/overflow desktop.)

I say "almost-maximized", because I use custom kwin window rules to keep 
those apps a title-bar's height shorter than full maximized.  That way, I 
can run a half-maxed browser/konsole/whatever on the same bottom monitor 
and still conveniently click-raise either the almost-maximized app or the 
other one, without trouble (focus follows mouse policy, click-to-raise, 
additionally, window transparency allows me to focus the "underneath" app 
and work in it "thru" the on-top app, when necessary -- this is why I find 
transparency almost indispensable now).

> After login, I
> have kontact running, many chromium windows/tabs, tvbrowser (java) which
> uses an awful lot of memory, amarok and kmymoney. Some plasmoids, some
> other tools, like gkrellm and such. When I work with the system, I
> occasionally start things like oowriter, gimp or gwenview, and don't
> quit immediately when I am done. This needs some memory, but I think
> when I do not touch the application, most of it should get swapped out
> when RAM gets low, and should be no trouble. Of course I get a delay
> when I start using it again as the application needs to get swapped in,
> that's okay.
> 
> My setup is so slow, for nearly a year I am thinking about dumping KDE4
> altogether - if it weren't so cool. And if I hadn't already put much
> time into tuning and configuration. With 4G of RAM is becomes unusable
> pretty soon, and even with 6G I get 2G of swap after a while. Well, at
> least part of this comes from a memory problem in plasma-desktop I
> think. Since I moved from 4.5.1 to 4.5.2, plasma-desktop started acting
> weirder. When I log in, or when I restart plasma-desktop manually, it
> takes minutes until the plasma stuff appears. During this phase, memory
> usage of the process climbs upwards until it reaches agout 1G, according
> to the RES column in top. And for some days now it crashes very often
> when I am using the comic plasmoid, which is not of much use anyway,
> because moreand more of the comics just do not work any more. When I
> close the plasmoid, memory usage is the same, so this is not the
> problem.
> 
> When I started with KDE 4.2, my setup was quite similar. I had only 3.5G
> of RAM and an i686 system instead of amd64 now (that hardware is
> identical), and there was no memory problem. I even added a 2G tmpfs
> sometimes in order to do compiles in memory. Things became a little slow
> when I used an application that needed 1.5G of memory, but performance
> was still better than now.
> 
> I'm using Gentoo Linux, so there is much compiling being done. I no
> longer do larger updates while I am working with the system, because of
> the slowdown. And it becomes especially annoying when watching movies or
> listening to music with amarok, and the sound stutters. All this was no
> problem at all one year ago.
> 
> I installed KDE 3.5 just to compare, and it seems to be much faster. But
> I got used to KDE 4, and would not want to switch back. Maybe I will, if
> things will not become better soon. First I will add another 2G of
> memory, and let's see if 8G will be enough then to make KDE4 run fast.

It's interesting that your experience is so different than mine, when 
we're both running KDE 4.5.2 on Gentoo.

Now while my system is somewhat old now (2004 era), it was well beyond the 
desktop system of the time, with dual socket Opteron (originally single-
core 1.6 GHz Opteron 242s, now dual-core 2.8 GHz Operon 290s, the top of 
the line as far as socket 940 goes).  If you're only running a single 
single-core, that's no doubt part of it, but it doesn't explain the memory 
issues you mention.

Originally, I had 8 gig (4 sticks @ 2 gig each) RAM, but one stick died 
and I've not replaced it, so I'm at 6 gig now.  But even with all the 
stuff I run, I wouldn't expect to have a problem even if I lost a second 
stick bringing it down to four gig, and in fact I'm on record as saying if 
I had it to do over, I'd get 4 1-gig sticks instead (the four sticks 
allows more efficient multi-channel memory access), since I'm seldom using 
more than 4 gig, INCLUDING CACHE.  While I do put the extra memory to work 
when I'm doing upgrades (using portage's parallel building,
MAKEOPTS="-j13 -l10" and defaulting to emerge --jobs=4 --load-average=7, 
with PORTAGE_TMPDIR in a 5 gig tmpfs), even that seldom pushes memory 
above 6 gigs usage into swap (it'll typically go a a few MB in, 10-20)
-- and that's even with kernel swappiness=100, so it's going to swap 
instead of dumping cache.

But there's three differences that I'd guess make up a majority of the 
difference:

1)  With a few noted exceptions, my general work pattern closes apps when 
not in use.  While I may run days to weeks without a reboot (and then it's 
usually to test a new kernel, I run direct linus mainline git and do 
regular pre-release kernel testing and bug reporting, among other things), 
and may run kde for days between kde restarts, typically, I don't keep 
/that/ many apps running.  In particular, firefox is said to be a big 
memory hog if left running for days at a time with a lot of tabs, and my 
default browser is konqueror and I don't often open more than a handful of 
tabs or keep them open for more than a few hours, max, so while I use 
firefox some, I just don't have the issues with it that many report, as I 
just don't use it that way.  Even with konqueror, tho, I tend to open a 
window, only open links in that window as new tabs, and only keep the 
window open a few hours, tho I often have three or more independent 
konqueror instances running at once.

I also don't run servantware (in the context of the sig) apps, so no flash 
or the like to bug out on me. =:^)

I'm not sure how multiple-desktops vs activities vs multiple-monitors 
affects plasma memory usage, but using the same single/dual (depending on 
how it's counted) activity on all three desktops and only having three 
desktops, can't /hurt/ memory usage, that's for sure.

It's worth noting that while your reported plasma-desktop memory usage, 
resident, according to top, reaches a gig, here, top does report it as the 
biggest resident memory user, but only by fractions of a MB, with both it 
and pan (ranked second) reported by top to have 93 MB resident.

FWIW, here's some other plasma mem numbers according to top:

VIRT 930 MB (virtual memory is the amount the app has asked the kernel to 
allocate, but traditionally, most apps use very little of it, such that 
the kernel over-commits by a rather big ratio, 50:1, by default, see
/proc/sys/vm/overcommit_ratio).

SWAP 838 MB (swappable, not necessarily swapped, as it isn't here since 
I'm running 0 MB swap ATM).

SHR 36 MB (shared, this memory is potentially shared between a number of 
apps using the same libs).

93 MB resident here vs a gig there?  Something tells me you've a problem, 
and one of the differences is your 8 desktops with an activity per 
desktop, vs my three desktops, same activity (or set of two activities 
back on kde 4.4, one per monitor) on each.

Also possibly of note while still on #1, you mention running chromium, 
which (like firefox but worse) bundles its own copies of many system 
libraries, so memory that's normally shared between apps using the same 
library is exclusive to chromium, with its bundled library copy.  As I 
said, firefox does some of the same thing, but at least on Gentoo, they've 
force-unbundled more of the libraries with firefox than with chromium, so 
it uses more of the shared system libs.  Another factor would be the 
separate VMs chromium uses for each tab, much stabler and more secure, but 
not exactly memory miserly.  If you're running the 50 tabs for days on end 
that I've seen some folks talking about running on firefox, that /might/ 
be part of it.

But so far, we definitely know something's up with your plasma, as a gig 
of resident really does seem abnormal.  Why?  Well, see #2 and #3.

2) I'm running gcc 4.5.1 here, with --as-needed in my LDFLAGS (it's there 
on Gentoo by default now, but that's a rather new change so if you've not 
done a full emerge --emptytree @world in awhile...).

Newer gccs might be a bit more efficient in that regard, and having the 
whole system built with the same compiler is likely to make system library 
memory sharing work better, I'd guess, as well.  The --as-needed in LDFLAGS 
might be a bigger factor, however, as otherwise the linker will link in 
libraries that really aren't needed, and if those are then loaded at 
runtime...  Note that I also have -z,now in my LDFLAGS.  That causes the 
loader to resolve all symbols at app init time, which will pull in more 
code then, but it then won't have to be pulled in later.  Normally that'd 
cause apps to use MORE memory, not less, but it's possible the effect of 
forcing initial symbol resolution allows more efficient library sharing, 
reversing the effect system-wide, I'm not sure.  But the effect will in 
any case be less with --as-needed as well, since less actually unneeded 
code will be linked and therefore force-loaded by the on-init loading.

It's also somewhat possible that an earlier version of gcc had a bug that 
I didn't run into with gcc 4.5.1.  Again, it's possible that having parts 
of the system compiled with different compilers could magnify the issue.  
It's not for nothing that Gentoo's gcc upgrade guide recommends doing an 
emerge --emptytree @world after a gcc upgrade, tho I normally only do it 
after feature version bumps (4.4 to 4.5, not the bugfix 4.5.0 to 4.5.1 
that I recently did, but I did an --emptytree recently for other reasons).

3) I know from personal experience that graphics hardware and drivers make 
a **HUGE** difference in how well kde4 runs.  "Drivers" includes not only 
the xorg driver, but the kernel dri/drm module as well, plus mesa, libdrm, 
and xorg.  I tend to run ahead of ~arch, as I'm running the xorg overlay, 
and I already mentioned I run mainline linus git kernels.  Also, I don't 
do servantware, so no nvidia/frglx here!

My graphics card is a Radeon hd4650 (r7xx series, my old one was an old 
Radeon 9200, r2xx series, thus the personal experience of the difference 
it makes!), and here's the graphics stack I'm running:

xf86-video-ati-6.13.2
xorg-server-1.9.1
mesa-7.9
libdrm-2.4.22
kernel (linus mainline) 2.6.36 (actually still a few git commits back from 
that, 2.6.36-rc8 plus a few commits, I've not upgraded since the proper 
release).

Again, those are recently recompiled along with the entire system using gcc 
4.5.1.

kde 4.5 does have known issues with certain graphics cards and drivers, 
including radeons, but it's said to be better if you're running the 
latest, which I am.  If you're running something older, or if you're 
running servantware drivers, or if it's not all compiled with the same gcc/
binutils, that could be part of it.  Actually, I'd not be surprised at all 
to find this was the biggest issue, right here, given the known issues in 
the area, and the abnormal gig resident for plasma-desktop you're 
reporting.

***BTW***

I'm seeing the comic-strip-plasmoid related crashes here as well.
After chasing down a different (non-kde) graphics bug I was seeing, I have 
a suspicion that I've not had time to verify.

What version of cairo are you running?  Here:

cairo-1.10.0-r3

Apparently cairo 1.10 "changed ownership semantics" in some way vs. 
previous versions.  That's in quotes because it's very close to the words 
used by the dev that traced down the non-kde bug I mentioned, and I don't 
know enough about cairo to have a clue.  But I do know that when he 
adapted his code to work with the new semantics, it did away with the 
problem.

Now, if I'm not mistaken, cairo originated as a gtk/gnome vector graphics 
rendering library, but it's used more widely now, including, it would seem 
according to equery depends, qt-gui and thus kde.

What I suspect but haven't yet verified is whether masking ~cairo-1.10.0, 
thus forcing a downgrade to cairo-1.8.10, suddenly resolves this bad comic-
strip-plasmoid crashing issue!

Perhaps you could try it and see?

***/BTW***

>> So I used the bisect method to track it down to a specific file, then
>> dove into that file with a text editor...
> 
> I've done this a couple of this, too. Very tedious, but better than
> starting from scratch.

When one has customized to the degree both of us have, it's DEFINITELY 
better than starting from scratch!

>> $KDEHOME/share/config/plasma-desktop-appletsrc

> I also found this file when analyzing why my activities were on the
> wrong desktops. I was able to fix this manually for some times by
> exchanging some of the numbers. When it happened again, I simply
> restored a backup copy of this file.
> 
> Oh, speaking of backups: I make lots of them. I never save the session
> without making one of my ~/.kde4 directory, because it often does not
> work and all applications open on the first desktop, for example. Or the
> plasmoids are all mixed up again.

Ugh!  FWIW, activity application tracking should be much improved with 
4.6, I've seen that blogged already, even tho I'm not following it as 
closely as I once did.

The mixed-up plasmoids... probably part of the same bug this whole thread 
is about, and hopefully fixed with 4.6 if not before.  But I don't know 
that for sure via blog of the dev.

> BTW, what I am missing is a possibility to move plasmoids around to
> other desktops/activities. Or is there already another method than
> deleting and re-creating a plasmoid? I'd also like the option to make
> them sticky on all activities, similar to windows being visible on all
> desktops. Even better would be the possibility to select multiple
> desktops/activities for plasmoids and windows.

Moving the plasmoids between activities... used to be possible using the 
zooming interface, I think, but I don't know how to do it using the new 
interface.  Of course it should be possible by directly editing that file 
mentioned above, changing the numbers appropriately, but that's definitely 
"advanced users only" territory, given the hassle involved ans risk of 
totally screwing the entire plasma config if one isn't careful.

The other stuff... there's STRONG hints in the blogs that this general 
type of thing is already what they're planning, and I definitely expect to 
see at least some of it for 4.6.  But I doubt we'll see anything like 
their full vision for activities before 4.8 or so (by which time they'll 
have even more ideas, of course)... another full year plus, from now.  
What the specific increments for 4.6, 4.7 and 4.8 might be, however, I 
couldn't guess at this point.

> Oh, and plasma-desktop just crashed again, when I gave the comic
> plasmoid anopther try. After 4 1/2 minutes, des desktop is back, and
> plasma-desktop takes 1.3G of memory. And I suddenly have a minimized
> 'JavaEmbeddedFrame' in my panel which I cannot maximize. It disappeared
> after a while.
> 
> Well, time to log out and in again, as I do every 1-2 days in order to
> make KDE4 fast again, at least for a while until the swapping starts
> again.

Hopefully something in the above is helpful, as a gig of resident for 
plasma-desktop... OUCH!

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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.