Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 310865 - Frequent plasma (4.4.1) crashes when changing settings, perhaps wrong rights, solved by activating compositing.
Summary: Frequent plasma (4.4.1) crashes when changing settings, perhaps wrong rights,...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
Depends on:
Blocks: 313999
  Show dependency tree
Reported: 2010-03-23 10:40 UTC by Navid Zamani
Modified: 2010-04-18 21:58 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---

emerge --info (emerge --info,5.14 KB, text/plain)
2010-03-28 16:48 UTC, Navid Zamani

Note You need to log in before you can comment on or make changes to this bug.
Description Navid Zamani 2010-03-23 10:40:27 UTC
Hello, I found something very interesting related to the plasma crashes. 
I had the following symptoms:
• Kdm never remembered my resolution (set via systemsettings or xrandr), and always reset it to 1024x768, with a weird small-scaling going on on the second display.
• Compositing couldn’t be activated. It complained about some app preventing it.
• Changing any plasma settings, either in the systemsettings, or by forcing windows e.g. to always maximize etc, had about a 42% chance of crashing plasma, and about 75% of those crashed X with them.

And now, lo and behold, the following behavior solves it:
1. chmod -R u=rwX .kde4
2. chown -R $USER:$USER .kde4
3. Go to a terminal (e.g. Ctrl-Alt-F2), kill plasma, and restart it (plasma-desktop --display :0).

The result:
✔ Compositing and all the desktop effects work
✔ Changing plasma settings does not cause any crashes anymore.
✔ X/kdm/KDE remembers the resolutions.
✘ Weirdly, the second workspace gets shifted to become the third, including all plasmids on it. A new workspace (with the default blue bg) replaces it.

Of course this is no permanent fix. I have to do it after every login. But a least the system is usable after that, and I am sure it helps you a lot, solving these bugs. :)

I’m happy to provide any additional information.
I’m running
• all of KDE in 4.4.1
• on a ATi Radeon HD 4850 (R700, so no open source driver yet)
• with the latest beta fglrx driver: ati-drivers-10.4_beta (Which allowed me or the first time, to start KDE at all. Previously plasma crashed at login, like in that other bug. But it does not *have* to be caused by fglrx. :)
• with ~amd64

Reproducible: Always

Steps to Reproduce:

[Set to critical because plasma hard crashes the desktop, causing data loss, severely hindering the configuration and usage of the desktop, and making it all around very annoying. (So much I thought about going back to KDE 3.5.10, just to be able to work again.)]
Comment 1 Maciej Mrozowski gentoo-dev 2010-03-27 13:11:23 UTC
Unable to reproduce.

Please show your emerge --info, as well.
If you use xdm/kdm, please examine ~/.xsession-errors, it should contain some meaningful information.
Also, if plasma crashes, you should be able to obtain its backtrace - read for more info.
Comment 2 Navid Zamani 2010-03-28 16:48:21 UTC
Created attachment 225583 [details]
emerge --info
Comment 3 Navid Zamani 2010-03-28 16:58:40 UTC
(In reply to comment #1)
> Unable to reproduce.
Oh, do you have the new ati-drivers-10.4_beta (as in bug 310367) installed and do you use them? (Requires xorg 1.7 too.)
If not, then maybe that’s the reason (wouldn’t surprise me, but needs to be proven). Can you reproduce it with that setup?

> Please show your emerge --info, as well.

> If you use xdm/kdm, please examine ~/.xsession-errors, it should contain some
> meaningful information.
That’s the thing. 1. It’s huge, and 2. I completely searched it, and found nothing that caught my eye. I’m just not skilled in reading Plasma/KDE log output, and don’t know what all the things are. But I didn’t found anything that could be an unusual (as in: wasn’t there with older versions of KDE, and is not known to be harmless) error or warning.

> Also, if plasma crashes, you should be able to obtain its backtrace - read
> for more info.
Wow, makes sense, but in my current situation (don’t know the C/GNU building environment at all) it could take months til I would have figured anything out. :/
Comment 4 Andreas K. Hüttel archtester gentoo-dev 2010-04-18 20:06:03 UTC
Does this still happen in 4.4.2?

The log file should me much smaller here, so it should be easier to spot anomalies...
Comment 5 Navid Zamani 2010-04-18 21:58:22 UTC
I switched to xorg 1.8, with
(via x11 overlay), and am now on KDE 4.4.2.

The crashes are gone, because compositing now always works. No idea if it still happens when I disable compositing.

I only still get plasma crashes from time to time because of another stupid bug:
Clicks on plasmoids have delays of reaction.
This is best explained by two examples:
1. When clicking on the cashew, the menu never goes away. Unless I first click, then wait about 2 or 3 seconds while still hovering the mouse at the same position, and only then move the mouse out of the cashew button area.
2. The same thing happens when moving plasmoids. Except that here they jump back to their previous position, as soon as I move the mouse outside of that dragging bar. Unless I wait those 2-3 seconds before doing so.

When I do those things in a hurry, clicking and moving too quickly, then suddenly, plasma completely crashes. But luckily, the rest of X survives. So either plasma restarts automatically, or I do it manually, and I’m good again.
I consider this a bug, but not this bug.
But I’m not annoyed enough to create a bug out of it. I’ll perhaps do so in the future.

So I mark this as WORKSFORME. If anyone still has the problem, feel free to either re-open the bug yourself, or ask me if you can’t. :)