Plasma Desktop Shell crash when shutting down

English Applications
1

Last week I updated my Thinkpad X60s laptop to 12.1 by doing a clean install but keeping my /home. Since then I’ve been experiencing a KDE Plasma Desktop Shell crash every time I shut my laptop down. If I start up and login and then shut down without doing anything else the system shuts down cleanly but if I start working and opening apps, etc then it crashes when shutting down. I have the following debug crash report which means nothing to me but may be helpful to someone here. Is there something obvious in there that points to the problem?

Application: Plasma Desktop Shell (kdeinit4), signal: Segmentation fault
[Current thread is 1 (Thread 0xb5732710 (LWP 2148))]

Thread 3 (Thread 0xaa4ffb70 (LWP 2156)):
#0  0xb5a64c96 in clock_gettime () from /lib/librt.so.1
#1  0xb6cc2c35 in do_gettime (frac=0xaa4ff020, sec=0xaa4ff018) at tools/qelapsedtimer_unix.cpp:123
#2  qt_gettime () at tools/qelapsedtimer_unix.cpp:140
#3  0xb6d95206 in QTimerInfoList::updateCurrentTime (this=0xa9b018bc) at kernel/qeventdispatcher_unix.cpp:339
#4  0xb6d9556a in QTimerInfoList::timerWait (this=0xa9b018bc, tm=...) at kernel/qeventdispatcher_unix.cpp:442
#5  0xb6d93dc3 in timerSourcePrepareHelper (src=<optimized out>, timeout=0xaa4ff12c) at kernel/qeventdispatcher_glib.cpp:136
#6  0xb6d93e5d in timerSourcePrepare (source=0xa9b01888, timeout=<optimized out>) at kernel/qeventdispatcher_glib.cpp:169
#7  0xb59ab44c in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#8  0xb59ac207 in ?? () from /usr/lib/libglib-2.0.so.0
#9  0xb59ac7fa in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#10 0xb6d94897 in QEventDispatcherGlib::processEvents (this=0xa9b00468, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#11 0xb6d6544d in QEventLoop::processEvents (this=0xaa4ff2b0, flags=...) at kernel/qeventloop.cpp:149
#12 0xb6d65691 in QEventLoop::exec (this=0xaa4ff2b0, flags=...) at kernel/qeventloop.cpp:201
#13 0xb6c6875b in QThread::exec (this=0x8724e20) at thread/qthread.cpp:498
#14 0xb6d4608d in QInotifyFileSystemWatcherEngine::run (this=0x8724e20) at io/qfilesystemwatcher_inotify.cpp:248
#15 0xb6c6b613 in QThreadPrivate::start (arg=0x8724e20) at thread/qthread_unix.cpp:331
#16 0xb6beea7d in start_thread () from /lib/libpthread.so.0
#17 0xb5fb789e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xa8afcb70 (LWP 2184)):
#0  0xb6bf0add in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0xb59ab2cb in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#2  0xb59ac207 in ?? () from /usr/lib/libglib-2.0.so.0
#3  0xb59ac7fa in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4  0xb6d94897 in QEventDispatcherGlib::processEvents (this=0x8dacd70, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#5  0xb6d6544d in QEventLoop::processEvents (this=0xa8afc2e0, flags=...) at kernel/qeventloop.cpp:149
#6  0xb6d65691 in QEventLoop::exec (this=0xa8afc2e0, flags=...) at kernel/qeventloop.cpp:201
#7  0xb6c6875b in QThread::exec (this=0x8c81008) at thread/qthread.cpp:498
#8  0xb4b200eb in Plasma::StorageThread::run (this=0x8c81008) at /usr/src/debug/kdelibs-4.7.2/plasma/private/storagethread.cpp:326
#9  0xb6c6b613 in QThreadPrivate::start (arg=0x8c81008) at thread/qthread_unix.cpp:331
#10 0xb6beea7d in start_thread () from /lib/libpthread.so.0
#11 0xb5fb789e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb5732710 (LWP 2148)):
[KCrash Handler]
#6  0x3ff00000 in ?? ()
#7  0xb082cbff in TaskGroupItem::~TaskGroupItem (this=0x9030080, __in_chrg=<optimized out>) at /usr/src/debug/kde-workspace-4.7.2/plasma/desktop/applets/tasks/taskgroupitem.cpp:82
#8  0xb082ccd2 in TaskGroupItem::~TaskGroupItem (this=0x9030080, __in_chrg=<optimized out>) at /usr/src/debug/kde-workspace-4.7.2/plasma/desktop/applets/tasks/taskgroupitem.cpp:83
#9  0xb6d79263 in qDeleteInEventHandler (o=0x9030080) at kernel/qobject.cpp:3995
#10 0xb6d7e858 in QObject::event (this=0x9030080, e=0x93b50a8) at kernel/qobject.cpp:1209
#11 0xb6941b84 in QGraphicsWidget::event (this=0x9030080, event=0x93b50a8) at graphicsview/qgraphicswidget.cpp:1455
#12 0xb6281f24 in notify_helper (e=0x93b50a8, receiver=0x9030080, this=0x80f5818) at kernel/qapplication.cpp:4481
#13 QApplicationPrivate::notify_helper (this=0x80f5818, receiver=0x9030080, e=0x93b50a8) at kernel/qapplication.cpp:4453
#14 0xb62872b2 in QApplication::notify (this=0x93b50a8, receiver=0x9030080, e=0x93b50a8) at kernel/qapplication.cpp:4228
#15 0xb74aa681 in KApplication::notify (this=0x80e08d0, receiver=0x9030080, event=0x93b50a8) at /usr/src/debug/kdelibs-4.7.2/kdeui/kernel/kapplication.cpp:311
#16 0xb6d6642e in QCoreApplication::notifyInternal (this=0x80e08d0, receiver=0x9030080, event=0x93b50a8) at kernel/qcoreapplication.cpp:787
#17 0xb6d69bf4 in sendEvent (event=<optimized out>, receiver=<optimized out>) at kernel/qcoreapplication.h:215
#18 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=52, data=0x805b1c0) at kernel/qcoreapplication.cpp:1428
#19 0xb6d69d3c in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=52) at kernel/qcoreapplication.cpp:1321
#20 0xb6d69e1d in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1071
#21 0xb627fda4 in QApplication::exec () at kernel/qapplication.cpp:3755
#22 0xb1d2e7cb in kdemain (argc=1, argv=0x80a7600) at /usr/src/debug/kde-workspace-4.7.2/plasma/desktop/shell/main.cpp:120
#23 0x0804fbcd in _start ()

Here are the last lines from the logfile which don’t really show any clues I think.

Jan 24 17:57:40 suntp001 polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.43, object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8)
Jan 24 17:58:43 suntp001 systemd-logind[905]: Removed session 2.
Jan 24 17:58:44 suntp001 dbus-daemon[973]: **** /proc/self/mountinfo changed
Jan 24 17:58:45 suntp001 dbus[973]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan 24 17:58:45 suntp001 dbus-daemon[973]: dbus[973]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
Jan 24 17:58:45 suntp001 avahi-daemon[967]: Withdrawing address record for 192.168.1.67 on eth0.
Jan 24 17:58:45 suntp001 avahi-daemon[967]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.67.
Jan 24 17:58:45 suntp001 avahi-daemon[967]: Interface eth0.IPv4 no longer relevant for mDNS.
Jan 24 17:58:45 suntp001 dbus[973]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan 24 17:58:45 suntp001 dbus-daemon[973]: dbus[973]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jan 24 17:58:46 suntp001 kernel: Kernel logging (proc) stopped.
Jan 24 17:58:46 suntp001 rsyslogd: [origin software="rsyslogd" swVersion="5.8.5" x-pid="955" x-info="http://www.rsyslog.com"] exiting on signal 15.
2

Did you do all of the available updates… I seem to recall there was one that addressed your issue…
Good luck.

3

Yes, system is fully up to date.

4

On 01/25/2012 02:46 PM, suse tpx60s wrote:
> system is fully up to date.

using Tumbleweed, or only oss+update?

are you using Apper to fetch updates?

if you open a terminal, and issue this command, does it show any updates
needed?


zypper up -t patch

if there are some waiting and you allow them to be installed and, if it
tells you to reboot, do so…if it does not say try shutting down
anyway, does it shut down without ‘crashing’?

if you shut down all applications prior to clicking to shut down, does
it ‘crash’?

what happens if you shut down all applications then open a
terminal/konsole/xterm and issue


/sbin/shutdown -h now

does it shutdown smoothly then?

has it ever shut down correctly?

when did it stop doing it correctly?

what changed? (last update, kernel change, application installed,
application uninstalled, config files edited, what?

and, please define what you mean “Desktop Shell Crash” that is, for example:

-does the desktop freeze while showing the “Turn off computer” button
dialog, or

-after you click that, that dialog goes away but you still see the rest
of the desktop but it freezes and never changes, or

-after clicking “Turn off computer” the screen goes black, but you can
see and move the mouse pointer, but it doesn’t ever shut down

-after after clicking “Turn off computer” the screen goes black, you can
see the mouse pointer but you can’t move it, and it never goes away…or,

-the mouse pointer does go away but the machine continues to run

-other?

–
DD
openSUSE®, the “German Engineered Automobiles” of operating systems!

5

Only using oss+update

I only perform updates manualiy through yast2 software manager. I turned off the auto updates checking.

One patch shown openSUSE-2012-25-1.noarch. Will install and see if it fixes the problem. Why doesn’t this show up in the yast2 software manager updates?

Yes

Haven’t tried it but will try it when I finish for the day.

Only when I shut down immediately after logging in, i.e. boot up log in then shut down.

Since I installed 12.1

The problem existed from the first shutdown after 12.1 was installed. So far no updates have fixed it.

When I click turn off computer, the screen goes black and then I’m presented with the crash handler window. The Plasma Desktop Shell is what was stated in the crash report

Application: Plasma Desktop Shell (kdeinit4), signal: Segmentation fault
. The mouse still works as I can then save the crash / debug log file. After I click close on the crash handler window the system shuts down fine.

6

On 01/25/2012 06:16 PM, suse tpx60s wrote:
> One patch shown openSUSE-2012-25-1.noarch. Will install and see if it
> fixes the problem. Why doesn’t this show up in the yast2 software
> manager updates?

no, i can’t answer that…afaik the zypper patch should show the same
thing as YaST Online Update…strange…

i will wait for your report on that and if that or “shutdown -h” works…

if other here has a better idea (or any idea) speak up…

OH! i know: next time you boot, at the first green screen press F5 and
then select “system V” (which is the old way of booting, 12.1 has a new
way called systemd which has problems for some people…a patch was
supposed to fix it, but maybe it didn’t fix it enough…)

–
DD http://tinyurl.com/DD-Caveat
READ all the neat stuff about openSUSE here http://tinyurl.com/SUSEonDW

7

An update:
Last night I tried the shutdown -h when shutting down for the day and the system shut down cleanly.

This morning I booted up and did an hour work and then tried a ‘normal’ shut down using the gui (clicking turn off computer). The system shut down cleanly again. So this is puzzling. I’ll try another shut down later today after the system has been up for a few hours and I’ve used more apps doing my work.

If I get the crash at shutdown again I’ll try booting with the system V option and see if that makes a difference.

I didn’t apply the patch as it relates to mozilla stuff (FF9 undate, mozilla-translations, etc) only. I’m running FF8 and not FF9 as FF9 seems to crash a lot for me while FF8 is completely stable.

8

Another update: The system shut down cleanly yesterday at the end of the day. At the moment I have no explanation why it’s working now as nothing has changed. I am assuming it must be something to do with how I interact with a plasmoid or other desktop widget during my days work.

9

On 01/27/2012 01:16 PM, suse tpx60s wrote:
> I am assuming it must be something to do with how I
> interact with a plasmoid or other desktop widget during my days work.

holler if you see the bad come back…if not, congrats…

–
DD
Read about openSUSE

10

Well the plasma desktop shell crash is back. It crashed on Friday and yesterday when shutting down for the day. I’ll try renaming the .kde4 directory and let it rebuild it when I log in and see if that works unless there is a better suggestion.

11

On 01/31/2012 09:26 AM, suse tpx60s wrote:
> Well the plasma desktop shell crash is back.

what changed?
did you do an update?

do you update with YaST Online Update, or some other way? how? maybe
zypper patch?

did you install some new software (like maybe a new KDE)? or delete
some? or log in as root and change some configs, or what?

–
DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

12

Nothing changed update wise. I did install Krename and that was all. This seems to be a bit of a random issue. It seems if I shutdown soon after logging in then it shuts down cleanly. But if I’ve worked for a few hours then it doesn’t shutdown cleanly so something I do during my working day triggers it. So whilst the problem is repeatable, it isn’t obvious what triggers the problem.

I renamed the .kde4 folder yesterday to allow a new one to be created when I log in but at the end of the day when I shut down I got the crash message again. Doesn’t the crash report I posted in the first post not give any clue? I’ve looked through it but it’s above my level of understanding.

My next step is to rename my user directory and let a new one to be built and see if that helps. The thing holding me back from wanting to do that is having to reconfigure everything and all the applications.

13

On 02/01/2012 09:36 AM, suse tpx60s wrote:
> Doesn’t the crash report I posted in the first post not
> give any clue? I’ve looked through it but it’s above my level of
> understanding.

above me also…(by a country mile)…maybe you should log a bugzilla,
at least that way someone who can understand it has the chance to look
it over…begin here: http://tinyurl.com/nzhq7j and when you have a bug
number and/or URL, please post that here, so anyone googling in and
finding this thread can go there and check the status…or add their
specific info to the same bug…

> My next step is to rename my user directory and let a new one to be
> built and see if that helps.

NO! that will not work, while KDE will build a new directory in your
home, openSUSE will not build a user’s /home once deleted! instead it
will BARF when you try to log in…

but, you can learn exactly the same outcome if you use YaST > Security
and Users > User and Group Management to add a new test user, with a new
password (do not forget it), then log out as yourself and log in as the
test user…and go do some stuff that you don’t have to have access to
your old home to do (i don’t know, browse the web for a while…what
ever) and then see how it goes…

> The thing holding me back from wanting to
> do that is having to reconfigure everything and all the applications.

that is a pain, i know…and i also know that if the new test user
account doesn’t show the same problem then it is almost certain that the
original user (heh) did something incorrect to cause the problem…

like: i would never let another distro touch my /home, nor would i move
from one distro to another without starting with a fresh, formatted home
and then move data in (never move in configs)…

same with moving from openSUSE 11.4 (or whatever) to any other newer
version…i always backup all data to a safe off machine spot and then
format /, /home, /swap and install fresh…then move data in…yes, i
know there are lots of folks who ‘upgrade’ from one distro to another,
or from one version to another…and, i see the thousands of strange
problems they grapple with, everyday.

ymmv

–
DD http://tinyurl.com/DD-Caveat
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

14

Thanks. I’ll try the new user account first and see if that shuts down properly. If not I’ll file a bug report as suggested.

I’ve preserved my /home folder over two upgrades so perhaps it’s time to just start with a fresh /home and move the data in as you suggest.

15

Update: I decided to bite the bullet and just create a new user account and move my data over from the old account. It’s taken 2 days of reconfiguring everything the way I had it before but at least the system is shutting down cleanly now so I guess the problem is solved.

16

On 02/03/2012 01:46 PM, suse tpx60s wrote:
> I guess the problem is solved.

well…i think it would be more correct to say the symptom has been
removed…

i mean, do we know what caused the crashes?

i don’t think we do, i guess the problem might have been, or what it
might be:

-in the sofware
-in the software set up
-in the hardware
-in the bios
-in the administration of the system

we can wait and see if the symptom returns…we hope it does not…

if it does, and if you have a good full backup you can restore from
backup to get right again…

and, the administrator can help the cause by reviewing patches/updates
before accepting them; never using apper; and being super careful when
acting as root, etc…

–
DD
Read what Distro Watch writes: http://tinyurl.com/SUSEonDW

17

Yep, you’re right. Well anyway it turns out the problem / symptom returned. After some checkin gon bugzilla it seems it is a common bug which got fixed in KDE4.7.4 so I upgraded to 4.7.4 and so far (3 shut downs) it’s been working fine. Hopefully it will stay fine now.

18

well, usually careful with predictions, but it seems, I have to say: thank You for Your hint:

zypper up -t patch

found about half a dozen updates on this way…
my crashes of kde4init on shutdown have stopped AND the problem of disappearing icons on the desktop & taskbar as well as within Mozilla apps seemed to have gone, too!!! lol!

thanks a lot DenverD

Al

19

Not wishing to spoil the party, but that’s from older versions (pre 11.3), so probably not in common use now.

To list all needed patch updates: # zypper lp

To list all available package updates: # zypper lu

20

well, it spoiled itself, Back to where we began… crashes back, vanished icons again… well, it was a try! :X