errr..
"Many times plasma
settings are overwritten and important configuration files for plasma, kmail
and other components are completely lost."

Are you saying this is the outcome of the segfault in the windowmanager (kwin) or do random components of you KDE desktop (like eg. plasma-desktop or kmail) crash and then loose their temporary settings (because of the unclean exit)

Flash + GL compositing in kwin causes indeed segfaults in some drivers or mesa, but that would cause other backtraces. This one looks related to KNotification (information popups, audio hints, i.e. "ching") and a bug in this lib would actually affect the entire desktop.

Hi Thomas,

I have disabled Desktop effects long ago just in case, because as you said, it's a possible source of issues. 

Typically, different components crash, sometimes the network management applet, sometimes plasma-desktop (and I can actually [alt-f2] and re run it), some times the system freezes (which I think means kwin segfaulting). Sometimes, a component crashes and I get the window to report a bug, and before I can do that, or just close that pop up, kwin crashes. 

So, whatever course of events, it seems like the config files are left in an inconsistent state whenever the desktop freezes and you need to power-cycle the computer. 

Many thanks!
Leo

First off: whenever you get a backtrace, does it always look like this? (in doubt: attach some ;-)

Whenever the "desktop freezes" try to ctrl+alt+f1 -> hopefully takes you to a VT, if not, there's a problem in X11 (or the kernel halts) and you'll have to do the "reisub" sysrequest. (since you're not using compositing, the lack of visual updates can NOT be caused by kwin - except it grabbed the server, but that's unlikely)

If there're visual updates (clock?) but you cannot change the active window and you can navigate to a VT, login "export DISPLAY=:0" and run "kwin --replace&".
Then use "ctrl+alt+F7" to switch back.

Last one: depending on your GPU/driver () you might wish to turn off KMS (pass "nomodeset radeon.modeset=0" to the kernel parameters at GRUB), but without further information, it's impossible to say where this bug source and it could even be caused by a broken HDD or broken RAM as well :-\
(run memtest and check SMART reports to rule out this)

Final note: even when X11 (the GUI) is completely out of order, try to cleanly shutdown the box from a VT, if you cannot even acces the VT anymore and happen to run an sshd and have a second computer, try to login via ssh and shut it down from there.
Pressing the reset button is about the last thing you should do - ever.

Thanks so much, Thomas, that's a good idea (attaching more backtraces). Sorry for not mentioning it, but yes, I have tried switching to another VT (ctrl+alt+f1 and such). This works when a KDE component crashes, but not if I reach the desktop freeze. I can't ssh with my machines for some network setup issue I have no time to look at :) Overall, I always try to avoid power cycling, and all your suggestions are great, but these seem like real kernel level crashes.

I will keep looking at this. Thanks for all the ideas. Yesterday I uninstalled some older KDE packages that needed to be kept installed to run ksensors. I'll see if that helps. I'll also try with and without KMS, though these crashes happen both with fglrx and radeon, so I am thinking it is something else. And you are right, it could be a hardware issue. If we conclude this is not a KDE issue I'll close this bug report right away (I am really trying to identify the bug, if any)

Cheers!
Leo

Hi,

A little update. Yesterday I removed the following OLD packages (they were being held up because I had ksensors installed from previous versions of kubuntu)

lmilano@grisell:~$ sudo dpkg -l |grep kdelibs4c2a
rc  kdelibs4c2a                                       4:3.5.10.dfsg.1-3ubuntu2.10.10.1                  core libraries and binaries for all KDE applications
lmilano@grisell:~$ sudo dpkg -l |grep kdelibs-data
rc  kdelibs-data                                      4:3.5.10.dfsg.1-3ubuntu2.10.10.1                  core shared data for all KDE applications

The system has been stable so far. I wonder if somehow these old packages were providing shared libraries that were being picked up by newer KDE packages (I noticed you guys use a pimpl pattern in some parts of the code), and probably reading uninitialized memory.

Anyways, let's see if it keeps being stable, I'll check back in a while. 

Thank you!

seems to be caused by a lib conflict. In case the removal did not help, feel free to reopen.

Yes, Martin, this makes sense. So far, the machine has been rock solid. Thank you, Thomas , for all the debugging ideas, you rock :)

Cheers!
Leo