phanisvara das posted on Fri, 29 Oct 2010 13:50:25 +0530 as excerpted:
> for the last week or so i'm experiencing plasma-desktop getting
> corrupted without any apparent reason: the standard panel disappears,
> additional activities 'create themselves,' and the desktop seems to be
> in front of running applications. app.s show up on alt+tab (task
> switcher), but are invisible behind the desktop. they react to
> keystrokes, like alt+F4, but don't show up. restarting plasma-desktop
> doesn't help in such situations. only deleting everything plasma-related
> from ~/.kde4/share remedies the situation.
>
> i'm not complaining: using factory such things are to be expected, and i
> have the awesome windows manager to fall back to if things should get
> worse. but i'd like to know if i'm the only one experiencing this, i.e,
> if i have messed up something in my box, or if this happens to others
> too?
I've no idea what "KDE factory" is. Maybe "as shipped by upstream"? What
kde version?
Meanwhile...
With 4.5.x here (currently 4.5.2 but I'm not sure if it was 4.5.2 when
this happened), I triggered something rather similar when I started
experimenting with adding activities, etc (it was for a reply to a list
post, in fact), and I had a plasma crash (initial plasma crash due to a
graphics related kernel bug on my particular hardware). After a couple
plasma crashes (triggered by the kernel bug), it was as if plasma decided
to create new versions of about three activities every time it was
restarted (new kde start, graceful plasma terminate and restart, crash,
didn't matter now), PLUS remembering the activities it had before, so I
very quickly developed a whole slew of activities.
I don't know what was causing it (after the initial trigger, anyway, other
than presumably plasma doesn't react as well as it might to a partially
corrupted config), but I have a heavily enough customized plasma setup
that I didn't want to lose all of it with a clean config, so I was quite
reluctant to go that route.
So I used the bisect method to track it down to a specific file, then dove
into that file with a text editor...
The bisect method is a reasonably simple if boring "brute force" method of
tracing a problem down. Many people use it, by various names, but it has
become popular lately by the name "bisect", as the git revision control
system has a tool by that name that automates the process in regard do
pinning a bug down to a specific commit. However, the technique works
well enough to narrow down the domain that it even has a popular social
game based on it -- "20 questions" -- you may have heard of it.
The idea is this. From outside of whatever is causing the problem (so
with a kde issue, from gnome or from a text login, without kde running,
for some things you may want to login as root, and do it with your whole
user home dir), backup the existing config. To ensure that you're on the
right track, it's recommended to simply rename the whole thing (the entire
~/.kde dir, for instance) the first time, so it's starting fresh.
Then start whatever is causing the problem (kde, in this case), and see if
the problem is gone. If it is, you've confirmed that you're on the right
track.
Now, shut down the problem (kde, here) again, and remove anything created
from the initial test. Now split the problem space roughly in half. Copy
about half the config back from backup, and repeat the test. Now, if the
problem is back, you know it's in the half you copied back. If it's not,
you know it's in the half you did NOT copy back.
If you copied the good half, you can leave it, and now copy back half of
what's left. If it was the bad half you copied, delete half of it, and
copy in the good half. Either way, you now have half of the config known
good and half bad, with the good half plus half of the bad half now in
place.
Repeat the test again... and again... each time reducing the suspect area
by roughly half.
Eventually, you'll narrow it down to a suspect dir, then a subdir, then an
individual file.
If you customize like me, at any point you can decide, "OK, I can recreate
what's left from here without too much problem, I'm done." But because I
like to actually find the problem, I generally keep going. The point at
which it gets down to an individual file is a natural point at which to
make that decision, because at that point you cease working with the
filesystem and start working with a text editor (assuming it's a text
based config file, like KDE's are, fortunately).
However, once I reached the individual file, which in at least my case was
$KDEHOME/share/config/plasma-desktop-appletsrc, I *STILL* had a huge
amount of customization invested in the thing that I didn't want to lose.
Basically, it appears that file contains the ENTIRE plasma desktop config,
ALL activities, ALL panels, ALL plasmoids on those panels! That's a *LOT*
of config to lose, for a heavy customizer such as myself. (IOW, I really /
do/ hope they make it a directory tree based config at some point, with a
top level file at the top of the tree, describing each panel and activity,
with a subdir for each one. Each subdir would then contain further files
and perhaps subdirs of its own, if it represents a container plasmoid, so
ultimately, losing or corrupting a single file isn't such a huge loss!)
So I had little choice but to continue with the text editor in that file
itself. Unfortunately, while the layout is text oriented, the file isn't
exactly designed to be easy to edit manually, as every widget is numbered,
and one has to manually track down what each numbered element represents.
Some are easier than others as they contain names or other config hints,
but it can still be difficult if there's multiple instances of a widget
configured -- say multiple panels, or multiple activities, as one then has
to sort out not just that it's an activity, but which one.
But eventually, using a combination of further bisection and simply
reasoning out what each section corresponded to, I made enough sense of
the format and how the the individual sections corresponded to various
plasma widgets, whether they be containers or plasmoids, that I was able
to trouble-shoot things, and eliminate all the multiplying activities,
etc, while keeping the two activities I actually use, plus the panels,
along with all but one of the individual plasmoids, intact.
In the process, I pruned several sections that were "lost" fragments of
config from widgets I had long since deleted, as well as whatever was
actually triggering the activity multiplication, etc.
So it's possible to do, if you have enough patience and reasoning power to
stare at the text config and reason out what each section does. I
mentioned the file that was the problem here, plasma-desktop-appletsrc,
and I expect your version is getting corrupted as well. If that proves to
be your problem, I've already eliminated all the bisection to the
individual file level that I had to do, for you.
What you'll need to do now is either using the same edit methods I did, or
simply from-scratch reconfiguration, try to pin down the multiplier
trigger to a single widget or action, and then avoid it like the plague!
You can then configure everything else to your liking, simply avoiding
whatever individual widget or action (in my case, it had something to do
with playing around with additional activities, but fortunately, my
existing config was stable enough and close enough to what I wanted that I
could stop doing that, thus ceasing to pull the trigger on more problems)
causes the issue, once you're otherwise configured to your liking.
Meanwhile, plasma-desktop is stable enough for me now, as long as I don't
go playing with activities too much. And if I DO decide to play with
them, you can be very sure I'm going to make a fresh copy of my stable and
working plasma-desktop-appletsrc before I do so, just in case! Then I can
play all I want, and knowing the file that's the problem if it gets
corrupted, simply restore it from backup if activities start multiplying
on me again or something! =:^)
--
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.
