KWin crashes multiple times a day and often has to be restarted manually.

Bug #1440210 reported by Ruman Gerst
112
This bug affects 23 people
Affects Status Importance Assigned to Milestone
KDE Base Workspace
Won't Fix
High
kwin (Ubuntu)
Won't Fix
Critical
Unassigned
Nominated for Vivid by Alberto Salvia Novella

Bug Description

I'm running Kubuntu 15.04 Beta 2 using an AMD based internal laptop graphics card (AMD R4) and fglrx (also tried fglrx-updates).

KWin crashed at random moments usually while changing the volume or display brightness (Plasma 5 shows a "tooltip" if I do this). KWin goes into a state of "halted" (if I watch the process in a task manager) and won't respawn automatically. I have to restart kwin_x11 manually using a console or KRunner.
In rare cases there's an error message, it says something about "DRI" (unfortunately I didn't save the crashlog) error caused by AMD's OpenGL library.

Also the content of Chrome and Firefox windows get "scrambled" (especially for chrome). Firefox usually gets a "double scrollbar" (until I scroll) and in Chrome you can see the triangles used for rendering if the view is updated somewhere (it looks like shattered glass). Also if you switch to Chrome, the window content is blue for a little time after things got into state of "Now I'm messed'.
Problems with Chrome stay if I restart kwin_x11 (Compositing on/off doesn't matter).

It also seems that some fonts of Plasma 5 get messed up, too.

I don't know if this is an error within kwin or fglrx.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: kwin 4:5.2.2a-0ubuntu1
ProcVersionSignature: Ubuntu 3.19.0-11.11-generic 3.19.3
Uname: Linux 3.19.0-11-generic x86_64
NonfreeKernelModules: fglrx wl
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
CurrentDesktop: KDE
Date: Fri Apr 3 22:48:15 2015
InstallationDate: Installed on 2015-03-11 (23 days ago)
InstallationMedia: Kubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150224.1)
SourcePackage: kwin
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

OS: Opensuse factory x86_64
KDE Framework 5.1
Plasma shell 5.0.1

After switching to plasma 5 desktop in opensuse factory, time to time desktop freezes. I can move mouse but nothing works. I can't click anywhere. I then restart session with CTRL+ALT+F7. I thought it is X.ORG or Kernel problem as it was freezing. But I didn't notice any such logs in /var/log/messages or X.org logs. Then once I hit ALT+TAB and desktop started behaving normal. Now I can always reproduce it. It keep freezing every few hours and I can resume it with ALT+TAB. So it seems something wrong with painting the desktop shell.

I usually use google chrome, dolphin, libreoffice, konsole and skype apps.

Reproducible: Always

Steps to Reproduce:
1. Use plasma desktop 5 for extended period of time.

Actual Results:
Desktop freezes

Expected Results:
Desktop should operate normally.

Revision history for this message
In , Cfeck (cfeck) wrote :

Could also be related to kwin. I remember that I got freezes when just running kwin/5 with Plasma 4.

Revision history for this message
In , U26 (u26) wrote :

Does this happened after disconnecting a monitor?

We need some more info before we can do anything on this. Maybe you can leave top/ksysguard open?

Does running
DISPLAY=:0 kwin_x11 --replace from a real terminal fix it?

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

I don't use secondary monitor. It randomly happens time to time on my laptop.
I didn't try that command because just hitting ALT+TAB fixes it. So seems like screen paint issue.

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

I just experienced again and checked top in other terminal, the output was normal.

Revision history for this message
In , U26 (u26) wrote :

If alt+tab fixes it it sounds like kwin is at fault.

Please attach the output of:
$ qdbus org.kde.kwin /KWin org.kde.KWin.supportInformation

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

Created attachment 88799
Kwin log

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

I highly suggest to switch to a different window decoration (Aurorae will not give you a good experience with your hardware).

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

Created attachment 88800
window decoration setting

Not sure why it shows aurorae, I'm using Breeze. I don't even have aurorae decoration. It just shows 3 options, breeze, oxygen and plastik.

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

Breeze uses Aurorae

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

a) define "freeze" - does any output update? (eg. a clock)?
     If not, does suspending the compositor (Shift+Alt+F12) turn the screen responsive again?

b) ctrl+alt+f7 should rather not restart the session.
     Is tihs really the case for you, or did you mean to restart the session from VT1 an then switch back to VT7?

c) Only interesting if output is still updated (ie. not compositing related)
    -> Install xdotool.
    When this happens the next time, on VT1 (or via ssh) run:
        DISPLAY=:0 xdotool key "XF86LogGrabInfo"
   then check /var/log/Xorg.0.log for device grabs:
      sed -n 'H; /Printing all currently active device grabs/h; ${g;p;}' /var/log/Xorg.0.log

(hint: you may want to stuff those commands into a bash script for easy calling. In case, put a "sleep 1" between the two commands)

Dev note:
could be related to bug #337853?

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

I checked all details. When it just happened. I had chrome and skype open.
a) It didn't update clock. Hitting ALT+SHIFT+F12 made taskbar responsive but desktop was still not responding. So I could launch new program. Open calendar, access systemtray but nothing will reflect on rest of the screen though. Eventually it crashed kwin and I could see applications without title bar.

b) CTRL+ALT+F7 had no effect.

c) No device grabs reported.

I had to restart kwin. It didn't trigger dr konqui after that though.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(In reply to Ruchir Brahmbhatt from comment #11)

> a) It didn't update clock. Hitting ALT+SHIFT+F12 made taskbar responsive but
> desktop was still not responding. So I could launch new program. Open
> calendar, access systemtray but nothing will reflect on rest of the screen
> though. Eventually it crashed kwin and I could see applications without
> title bar.

This makes no sense (ie. seems self-contradicting)

For clarification:
after suspending the compositor, (some) *present* windows turned responsive, but you could not get *new* windows on screen?
Could you pass the focus around among existing windows (eg. make firefox the active window and then konsole etc.)?

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

After suspending compositor, taskbar turned responsive but no windows were responsive. Last window is shown on screen. Nothing happens when I select other windows I still see google chrome only. I tried to start dolphin from launcher which didn't start though and I think kwin crashed after that. Was very weird and confusing behavior.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

See bug #313830

Do you eventually use XIM (or "fcitx")?
Can you gdb into the frozen kwin from VT1?

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

I could gdb into frozen kwin and got below bt. I don't understand the XIM part.

(gdb) bt
#0 0x00007ff9a7668a63 in select () from /lib64/libc.so.6
#1 0x00007ff9a57b6cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5
#2 0x00007ff9a57b862f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5
#3 0x00007ff9a57b8a8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007ff991bed8ed in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so
#5 0x00007ff9a5761a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6 0x00007ff9a57690c6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#7 0x00007ff9a7936beb in kdemain (argc=1, argv=0x7fff83c24d98) at /usr/src/debug/kwin-5.0.95~git20140911/main_x11.cpp:294
#8 0x00007ff9a75abb05 in __libc_start_main () from /lib64/libc.so.6
#9 0x00000000004008ce in _start () at ../sysdeps/x86_64/start.S:122

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

That thread seems dormant, you want to inspect the existing threads and switch between them, see eg. https://sourceware.org/gdb/current/onlinedocs/gdb/Threads.html

XIM is for input of non-latin text - it's often used in asia, but i don't know about india.
http://en.wikipedia.org/wiki/Fcitx

It's also known for the potential to stall xcb event processing:
https://bugs.kde.org/show_bug.cgi?id=313830

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :
Download full text (4.9 KiB)

I use english language only so probably XIM is not in use. Please find bt of all threads below.

(gdb) info threads
  Id Target Id Frame
  5 Thread 0x7fe6a346c700 (LWP 1505) "QXcbEventReader" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4 Thread 0x7fe6a0985700 (LWP 1508) "QProcessManager" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
  3 Thread 0x7fe693bb1700 (LWP 1532) "QQmlThread" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
  2 Thread 0x7fe68bfff700 (LWP 1548) "kwin_x11" 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 1 Thread 0x7fe6ba26d800 (LWP 1502) "kwin_x11" 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
#1 0x00007fe6b7d58cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5
#2 0x00007fe6b7d5a62f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5
#3 0x00007fe6b7d5aa8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe6a418f8ed in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so
#5 0x00007fe6b7d03a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6 0x00007fe6b7d0b0c6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe6b9ed8beb in kdemain (argc=1, argv=0x7fffbc4e4588) at /usr/src/debug/kwin-5.0.95~git20140911/main_x11.cpp:294
#8 0x00007fe6b9b4db05 in __libc_start_main () from /lib64/libc.so.6
#9 0x00000000004008ce in _start () at ../sysdeps/x86_64/start.S:122
(gdb) thread 2
[Switching to thread 2 (Thread 0x7fe68bfff700 (LWP 1548))]
#0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
(gdb) bt
#0 0x00007fe6b09f805f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007fe6b60d8fbb in ?? () from /usr/lib64/libQt5Script.so.5
#2 0x00007fe6b60d8fe9 in ?? () from /usr/lib64/libQt5Script.so.5
#3 0x00007fe6b09f40a4 in start_thread () from /lib64/libpthread.so.0
#4 0x00007fe6b9c117fd in clone () from /lib64/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 0x7fe693bb1700 (LWP 1532))]
#0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fe6b9c0aa63 in select () from /lib64/libc.so.6
#1 0x00007fe6b7d58cb9 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5
#2 0x00007fe6b7d5a62f in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timespec*) () from /usr/lib64/libQt5Core.so.5
#3 0x00007fe6b7d5aa8b in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4 0x00007fe6b7d03a6b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5 0x00007fe6b7b22eca in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5
#7 0x00007fe6b09f40a4 in start_thread () fro...

Read more...

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

> #3 0x00007fe6a41400c9 in ?? () from /usr/lib64/qt5/plugins/platforms/libqxcb.so
> #4 0x00007fe6b7b27b3f in ?? () from /usr/lib64/libQt5Core.so.5

Unfortunately there're no debug symbols, yet
> #2 0x00007fe6b7871def in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
it seems to hang in xcb_wait_for_event (like the xim bug, which however may just be a xim *induced* bug in Qt)

You're now running the oxygen deco, I assume?
Let's see whether it happens with this as well ;-)

Revision history for this message
In , Mgraesslin (mgraesslin) wrote :

> > #2 0x00007fe6b7871def in xcb_wait_for_event () from
> > /usr/lib64/libxcb.so.1
>
> it seems to hang in xcb_wait_for_event (like the xim bug, which however may
> just be a xim *induced* bug in Qt)

well that's what the xcb event reading thread is supposed to do. Hang there
and wait for the next event.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

yes, but from the description, events are not received/processed and no other thread seems locked at some point...
i didn't mean "this is the cause", but "this seems the relevat symptom" (at least i can't see any other)

we might have "lost" the xcb connection or just event selection.
no ida on the cause, though.

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

Just an update, keeping compositor off doesn't freeze desktop anymore. I could use full day without single freeze.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

Did you hit it with oxygen deco + compositing?

Revision history for this message
In , Ruchir (ruchir-brahmbhatt) wrote :

Yes due to bug #339235, I used oxygen instead of breeze and yet it was freezing. After disabling compositing, it no longer freezes.

Revision history for this message
In , K6j-fdedria-zp0 (k6j-fdedria-zp0) wrote :

A possible cause is kwin calling SwapBuffers() from prepareRenderingFrame().

With Qt 5 kwin must return to the event loop after calling SwapBuffers(), or Mesa won't see the buffer invalidate event and rendering will be lost.

Revision history for this message
In , doc81 (robby-engelmann) wrote :

 Using Plasma 5.1beta on openSUSE, I also have irregular occurring freezes like described here.

Revision history for this message
In , Sudhir Khanger (sudhirkhanger) wrote :

Does your screen look anything like this http://i.imgur.com/wWP91KJ.jpg when it gets frozen?

Revision history for this message
In , doc81 (robby-engelmann) wrote :

your screen looks like another bug, i see regularly. is it combined with flickering?

Revision history for this message
In , Sudhir Khanger (sudhirkhanger) wrote :

There maybe flicker I am not 100% sure. Mouse works. From what I can tell everything is running in back ground. I can run commands through KRunner. I think some application gets frozen and blackened in front which makes everything behind it unusable. My rough guess is Breeze Window decoration is behind it. I have reinstalled Plasma 5 from scratch. I am slowly changing defaults theme defaults one at a time. As far as graphics is considered Breeze window decoration is the only thing that I don't have right now.

Revision history for this message
In , doc81 (robby-engelmann) wrote :

short update: using plasma 5.1 final and KF 5.3 the bug is still occuring. When I deactivate compositing it is gone.

Revision history for this message
In , Sean Watson (sean.watson) wrote :

Rolling back to an old version at: https://build.opensuse.org/package/show?project=home%3Asumski%3Atest&package=xf86-video-intel seems to have fixed the freezing problem.

Mesa updated to 10.3.1 and intel .916 didn't fix the problem.

It is version 2.99.911 versus Factory's 916, and the biggest apparent difference is that there is no DRI3 in the old one. So it seems there is a problem with new intel drivers with Gen4.5 with DRI3.

Revision history for this message
In , Cfeck (cfeck) wrote :

I also had the freezes with intel, but I did only use openSUSE 13.1 versions, which still has Mesa 9.2.3 and intel 2.99.906. Chipset is 945GM (8086:27a2 / 8086:27a6).

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

Check:
grep -i glamor /var/log/Xorg.0.log

Revision history for this message
In , Kyrylo Bohdanenko (kyrboh) wrote :

Sorry, for interrupting, but here is some more information on this bug.

As I have noticed, this freeze happens more frequently when picture on the screen is changing fast & abundantly (i.e. watching a full-screen|part-screen video, scrolling a page in browser, using visualizer in Amarok). And when there's almost nothing happening on the screen -- it's almost imposible to reproduce the bug.

I am using:
* Plasma 5.1 on top of Kubuntu 14.10 x86_64
* KDE Frameworks 5.3
* Intel HD 3000 video (Sandy Bridge)
* xserver-xorg-video-intel: 2:2.99.914-1~exp1ubuntu4.1
* mesa: 10.3.0-0ubuntu3

$ grep -i glamor /var/log/Xorg.0.log
[ 22.827] (WW) "glamoregl" will not be loaded unless you've specified it to be loaded elsewhere.d elsewher

KWin support information: http://paste.kde.org/p0bhhaqly

Please do not hezitate to ask, if you will need some more information from me.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

> Painting blocks for vertical retrace: no
*Should* rule out comment #24 because KWin's then calling present() from endRenderingFrame(), invalidating lastDamage()

Can someone try
   export KWIN_USE_BUFFER_AGE=0; kwin --replace &

38 comments hidden view all 173 comments
Revision history for this message
Ruman Gerst (mrboese) wrote :
Revision history for this message
Ruman Gerst (mrboese) wrote :

Another image showing the problems with Chrome

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in kwin (Ubuntu):
status: New → Confirmed
Revision history for this message
Matteo Croce (teknoraver) wrote :

That's really annoying because I have to continuously restart kwin

Revision history for this message
Matteo Croce (teknoraver) wrote :

Maybe it's like this upstream

https://bugs.kde.org/show_bug.cgi?id=338999

Changed in kwin (Ubuntu):
importance: Undecided → Critical
assignee: nobody → Alberto Salvia Novella (es20490446e)
status: Confirmed → In Progress
Changed in kwin (Ubuntu):
assignee: Alberto Salvia Novella (es20490446e) → nobody
status: In Progress → Confirmed
Changed in kdebase-workspace:
importance: Undecided → Unknown
status: New → Unknown
Changed in kwin (Ubuntu):
status: Confirmed → Triaged
Changed in kdebase-workspace:
importance: Unknown → High
status: Unknown → New
128 comments hidden view all 173 comments
Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

that's still unspecific, because it's not clear wheter a (all) clients do not repaint or are entirely stalled or the compositor doesn't update or is stalled.

if shift+alt+f12 works only the compositor doesn't update, if not, it either doesn't respond or the issue is in the clients ("applications", including the desktop shell) or X11.

For any progress, it's crucial to localize the problem - it's not possible to fix symptoms.

Revision history for this message
In , emr (emrecio) wrote :

(In reply to Thomas Lübking from comment #125)

> Be reminded that this bug will *never* fix since it turned into a random
> "something doesn't work" report mess.

Which is why I stopped using KDE, opting for LxQT.

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

(In reply to Thomas Lübking from comment #125)
> If you can move to another VT it's unlikely required to reboot the system.
> First try to suspend the compositor (SHIFT+Alt+F12), notably if *everything*
> hangs (visually, you can actually inspect the condition of random processes
> from the other VT)
>
> If that "helps", resume it (same shortcut), obtain the output of
> qdbus org.kde.KWin /KWin supportInformation
> and file a new bug.
>
> Be reminded that this bug will *never* fix since it turned into a random
> "something doesn't work" report mess.

At the morning screen is blank (screensaver), mouse move open desktop as a picture. SHIFT+Alt+F12 doesn't work, qdbus answers
"Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network c
onnection was broken."
That's because of KDE: if I log off at evening, at the morning I can log in and all's working.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(In reply to EMR_Kde from comment #128)
> > Be reminded that this bug will *never* fix since it turned into a random
> > "something doesn't work" report mess.

> Which is why I stopped using KDE, opting for LxQT.

Because KDE users sometimes flood a bug with so many unrelated "I have a problem as well" comments that at some point nobody can say what the problem in the bugreport actually is?

The first 24 comments are a valid bug, the rest started to mess up things with every post. Sorry.

Comment #56 seems to indicate it was a problem with the intel driver, maybe then still used by default intel swap events.

And if you're not using KDE, what the heck are you doing here?

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(In reply to SinClaus from comment #129)

> At the morning screen is blank (screensaver), mouse move open desktop as a
> picture. SHIFT+Alt+F12 doesn't work, qdbus answers
> "Error: org.freedesktop.DBus.Error.NoReply
> Did not receive a reply. Possible causes include: the remote application did
> not send a reply, the message bus security policy blocked the reply, the
> reply timeout expired, or the network c
> onnection was broken."

That sounds as if the kwin_x11 process stalled, but if the screen is locked, it's expectable that SHIFT+Alt+F12 doesn't work (all input is grabbed by the screen locker which might be the troublemaker here)

==> does this also happen if you do *not* lock the screen with suspending to ram??

If yes, check if kwin_x11 running and not just sigstopped ("ps ax | grep kwin_x11" lists it with "TN" instead of "SN")
If it is, gdb into it to obtain a backtrace on the location where it's stalled.

Howto do that (using ssh is preferable, to not alter the inspected system by changing to another VT)
https://community.kde.org/KWin/Debugging

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

(In reply to Thomas Lübking from comment #131)
> (In reply to SinClaus from comment #129)
>
>
> That sounds as if the kwin_x11 process stalled, but if the screen is locked,
> it's expectable that SHIFT+Alt+F12 doesn't work (all input is grabbed by the
> screen locker which might be the troublemaker here)
>
> ==> does this also happen if you do *not* lock the screen with suspending to
> ram??
>
> If yes, check if kwin_x11 running and not just sigstopped ("ps ax | grep
> kwin_x11" lists it with "TN" instead of "SN")
> If it is, gdb into it to obtain a backtrace on the location where it's
> stalled.
>
> Howto do that (using ssh is preferable, to not alter the inspected system by
> changing to another VT)
> https://community.kde.org/KWin/Debugging

I don't know how other Linux, but in Arch we don't have screen lock, it's it was simple screen off.
Because hangs only plasma, I can switch to another VT.

Revision history for this message
In , Kde-t (kde-t) wrote :

My issue is not a "screen lock" either, just plasmashell locking up as the original bug & title state.
I can still task switch, VT switch, use my programs, etc. just the desktop and panels+widgets are non-op & plasmashell has to be force-killed and re-launched.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

The original bug was *not* about the plasmashell process, but the entire session (unless suspending the compositor what in return made everything but the plasmashell desktop responsive at least, I suspect an intel driver issue, but we never figured it. Notably Ruchir stated that "Alt+Tab" would "fix" it)

@SinClaus
The screenlocker is unrelated to the kernel or the distro, but part of the ksmserver process (KDE feature) - I don't know the default behavior for STR, but it /can/ activate with it.

To check whether your session is locked, try

   export DISPLAY=:0
   qdbus org.freedesktop.ScreenSaver /ScreenSaver GetActive

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

I've unchecked "start composer on system start", and it seems that system is working next day.
Here is answer (through ssh)
qdbus org.kde.KWin /KWin
signal void org.kde.KWin.reloadConfig()
method Q_NOREPLY void org.kde.KWin.cascadeDesktop()
method int org.kde.KWin.currentDesktop()
method Q_NOREPLY void org.kde.KWin.killWindow()
method void org.kde.KWin.nextDesktop()
method void org.kde.KWin.previousDesktop()
method Q_NOREPLY void org.kde.KWin.reconfigure()
method bool org.kde.KWin.setCurrentDesktop(int desktop)
method bool org.kde.KWin.startActivity(QString)
method bool org.kde.KWin.stopActivity(QString)
method QString org.kde.KWin.supportInformation()
method Q_NOREPLY void org.kde.KWin.unclutterDesktop()
signal void org.freedesktop.DBus.Properties.PropertiesChanged(QString interface_name, QVariantMap changed_properties, QStringList invalidated_properties)
method QDBusVariant org.freedesktop.DBus.Properties.Get(QString interface_name, QString property_name)
method QVariantMap org.freedesktop.DBus.Properties.GetAll(QString interface_name)
method void org.freedesktop.DBus.Properties.Set(QString interface_name, QString property_name, QDBusVariant value)
method QString org.freedesktop.DBus.Introspectable.Introspect()
method QString org.freedesktop.DBus.Peer.GetMachineId()
method void org.freedesktop.DBus.Peer.Ping()

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

That sounds like a stalled kwin process.

Please file a new bug and there attach the output of
   qdbus org.kde.KWin /KWin supportInformation

(obtain it while the compositor is running "ok" - you can toggle the compositor anytime with SHIFT+Alt+F12)

Also, if possible obtain and attach a backtrace for the stalled kwin process, according to https://community.kde.org/KWin/Debugging

(but first just file the bug with teh information instantly available)

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

(In reply to Thomas Lübking from comment #136)
> That sounds like a stalled kwin process.
>
> Please file a new bug and there attach the output of
> qdbus org.kde.KWin /KWin supportInformation
>
> (obtain it while the compositor is running "ok" - you can toggle the
> compositor anytime with SHIFT+Alt+F12)
>
> Also, if possible obtain and attach a backtrace for the stalled kwin
> process, according to https://community.kde.org/KWin/Debugging
>
> (but first just file the bug with teh information instantly available)

OK, I'll try make it in a monday.

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

I've open new Bug 353587

Revision history for this message
In , dovidhalevi (d-baron) wrote :

Time to treat this. Plasma becoming almost unusable.
Get repeated nouveau cache read errors which will hang the system.
Could be disk-oriented, may not.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

If you've a specific error, please file a new bug and log the errors there.

*This* bug is meanwhile a mess of random "somthing doesn't work" reports (full /var, corrupted plasma theme caches, whatnot else) and can thus never be treated nor fixed.

Revision history for this message
In , Kyrylo Bohdanenko (kyrboh) wrote :

Hi Thomas,

I think this report should then be closed as invalid. Comments in this thread (useful information) should be splitted into separate reports. Because this report here serves nothing but a garbage bin.

BTW, for me the issue described in name is solved: first I used a workaround KWIN_USE_BUFFER_AGE=0, then the issue dissapeared completely (not using the workaroud now).

Revision history for this message
In , dovidhalevi (d-baron) wrote :

On Monday 26 October 2015 22:36:29 you wrote:
> KWIN_USE_BUFFER_AGE=0

How do you use this?

Revision history for this message
In , Kyrylo Bohdanenko (kyrboh) wrote :

> KWIN_USE_BUFFER_AGE=0

As I said, I do not use this anymore. However, what I used in the past was:

$ cat > /etc/profile.d/kwin-fix.sh
export KWIN_USE_BUFFER_AGE=0

$ chown root:root /etc/profile.d/kwin-fix.sh

$ chmod 0644 /etc/profile.d/kwin-fix. sh

Revision history for this message
In , dovidhalevi (d-baron) wrote :

On Tuesday 27 October 2015 08:27:53 Kirill Bogdanenko via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=338999
>
> --- Comment #143 from Kirill Bogdanenko <email address hidden> ---
>
> > KWIN_USE_BUFFER_AGE=0
>
> As I said, I do not use this anymore. However, what I used in the past was:
>
> $ cat > /etc/profile.d/kwin-fix.sh
> export KWIN_USE_BUFFER_AGE=0
>
> $ chown root:root /etc/profile.d/kwin-fix.sh
>
> $ chmod 0644 /etc/profile.d/kwin-fix. sh

Works so far.
Only get the buffer errors from a "smart-notifier" on kde start up. None from
iceweasel so far (which was I prime offender).

So far, so good.

Revision history for this message
In , dovidhalevi (d-baron) wrote :

On Tuesday 27 October 2015 08:27:53 you wrote:
> https://bugs.kde.org/show_bug.cgi?id=338999
>
> --- Comment #143 from Kirill Bogdanenko <email address hidden> ---
>
> > KWIN_USE_BUFFER_AGE=0
>
> As I said, I do not use this anymore. However, what I used in the past was:
>
> $ cat > /etc/profile.d/kwin-fix.sh
> export KWIN_USE_BUFFER_AGE=0
>
> $ chown root:root /etc/profile.d/kwin-fix.sh
>
> $ chmod 0644 /etc/profile.d/kwin-fix. sh

Or ,,, maybe spoke too soon. Got these from iceweasel:
[ 2758.941564] nouveau E[ PFIFO][0000:01:00.0] CACHE_ERROR - ch 18
[iceweasel[6983]] subc 5 mthd 0x0180 data 0xbeef0301
[ 2758.941579] nouveau E[ PGR][0000:01:00.0] ERROR nsource: ILLEGAL_MTHD
nstatus: PROTECTION_FAULT

Interesting.

See how harmful these are.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

See eg. http://forums.fedoraforum.org/archive/index.php/t-247253.html

Please notice that nouveau has nowhere production quality reg. OpenGL - Plasma 5 with its pleathora of GL contexts is likely just "too much".
Unless you've a very strong reason (unsupported HW) resort to the nvidia blob.
Otherwise I suggest to avoid OpenGL as much as possible (ie. disable HW acceleration in firefox etc, use xrender compositing) in case of troubles.
And ensure to run recent kernel and mesa versions (not stable/reliable at all, but likely less static bugs)

Revision history for this message
In , dovidhalevi (d-baron) wrote :

Created attachment 95164
attachment-15798-0.html

Most probably correct, except did not have problems until recent Sid upgrades. Situation is getting worse, cannot even get plasmashell up without a freeze, writing this on a live CD. I suspect this was from the disk, but if that cache is on a disk, it is not on the suspect disk, and I am beginning to suspect smartctl more than the disks.I would like to get back up, make sure xrender is chosen and disable all desktop effects. Should be better behaved.The kwin fix was OK until I rebooted, then plasmashell would not start so removed the file. Probably based on an older version in any event.----- Original Message -----From: Thomas Lübking via KDE Bugzilla  <email address hidden>Date: Tuesday, October 27, 2015 3:52 pmSubject: [kwin] [Bug 338999] [unspecific] Desktop freezes time to time on plasma 5 (collection of various unrelated problems, WONTFIX)To: d_baron@012.net.il> https://bugs.kde.org/show_bug.cgi?id=338999> > --- Comment #146 from Thomas Lübking > <email address hidden> ---> See eg. http://forums.fedoraforum.org/archive/index.php/t-247253.html> > Please notice that nouveau has nowhere production quality reg. > OpenGL - Plasma> 5 with its pleathora of GL contexts is likely just "too much".> Unless you've a very strong reason (unsupported HW) resort to > the nvidia blob.> Otherwise I suggest to avoid OpenGL as much as possible (ie. > disable HW> acceleration in firefox etc, use xrender compositing) in case of > troubles.And ensure to run recent kernel and mesa versions (not > stable/reliable at all,> but likely less static bugs)> > -- > You are receiving this mail because:> You are on the CC list for the bug.‭‮

Revision history for this message
In , dovidhalevi (d-baron) wrote :

Sorry for the mess. Must remember to specify plain text each time (not default) in the provider's mail site.

Suggestion to simply remove /.cache? This is on a maybe problematic disk. I would assume if this is being used, KDE would just make a new one.

Since 1. The system-settings item to turn off compositing, select xrender, itself, freezes things so I cannot get to it, and 2. I will sometimes not even get far enough in plasmashell start up to do alt/shift/F12 at least -- is there any way I can set these manually so all KDE sessions will default this way?

Revision history for this message
In , Bogdan Hlevca (a-bogdan) wrote :

I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3.
Most KDE applications freeze for 30 seconds when you start them. It is not only kate or okular. It is dophin and many others.

This happens on my desktop system on which I have a Nvidia Quatro 620 semi professional video card.

I have the same system on a laptop with an Intel HD video chip and this problems do not occur.

I this thing pissed me off so I did more research and I figured out that if you change the window manager from kwin5 to something else, for example Openbox, the problem goes away, There is obviously a problem Kwin5 has with the Nvidia driver (I have the proprietary one)

There is no need to keep this unconfirmed just because you don't have an NVIDIA card and can't reproduce it.

1 comments hidden view all 173 comments
Revision history for this message
In , Bogdan Hlevca (a-bogdan) wrote :

(In reply to bogdan from comment #150)

I apologize, Opensuse 42.1 comes with plasms 5.4.3

Revision history for this message
In , dovidhalevi (d-baron) wrote :

Problem with the bug is the unspecificity (is that a word?).
The problem is Nvidia and Nouveau. I solved it, as recommended, by using the
proprietary driver.
Guess what? If it were not freezing up, I would go back to Nouveau. Flash (OK,
time to ditch that!) and Vimeo malfunction or do not work at all. The only
thing that is really better with Nvidia's own is flightgear and I do not have
enough room for it anyway.

> https://bugs.kde.org/show_bug.cgi?id=338999
>
> <email address hidden> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |<email address hidden>
>
> --- Comment #149 from <email address hidden> ---
> I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3.
> Most KDE applications freeze for 30 seconds when you start them. It is not
> only kate or okular. It is dophin and many others.
>
> This happens on my desktop system on which I have a Nvidia Quatro 620 semi
> professional video card.
>
> I have the same system on a laptop with an Intel HD video chip and this
> problems do not occur.
>
> I this thing pissed me off so I did more research and I figured out that if
> you change the window manager from kwin5 to something else, for example
> Openbox, the problem goes away, There is obviously a problem Kwin5 has with
> the Nvidia driver (I have the proprietary one)
>
> There is no need to keep this unconfirmed just because you don't have an
> NVIDIA card and can't reproduce it.
>
> --- Comment #150 from <email address hidden> ---
> I tested extensively in OpenSUSE 42.1 which comes with Plasma 5.3.
> Most KDE applications freeze for 30 seconds when you start them. It is not
> only kate or okular. It is dophin and many others.
>
> This happens on my desktop system on which I have a Nvidia Quatro 620 semi
> professional video card.
>
> I have the same system on a laptop with an Intel HD video chip and this
> problems do not occur.
>
> I this thing pissed me off so I did more research and I figured out that if
> you change the window manager from kwin5 to something else, for example
> Openbox, the problem goes away, There is obviously a problem Kwin5 has with
> the Nvidia driver (I have the proprietary one)
>
> There is no need to keep this unconfirmed just because you don't have an
> NVIDIA card and can't reproduce it.

Revision history for this message
In , Bogdan Hlevca (a-bogdan) wrote :

The problem is NOT the Nouveau driver. I have the proprietary one and I still have the 30 seconds freezing problem when I start a KDE application. There are no issues for non KDE applications.

The problem, as I already mentioned in my original message, is kwin with any driver for Nvidia. As soon as I changed the window manager to Openbox ( you can change it in System settings Applications -> Default Application) the problem disappeared. Of course some KDE functionality is lost.

In addition Plasma 5 crashes in different circumstances, most related to power management, but these issues are reported in different places and are not related to kwin, it happens with Openbox as well.

(In reply to David Baron from comment #152)
> Problem with the bug is the unspecificity (is that a word?).
> The problem is Nvidia and Nouveau. I solved it, as recommended, by using the
> proprietary driver.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

IPORTANT NOTICE:
*this* bug entry has long tiem turned a completely poinless mess of various "something does not work" reports on contradicting problem descriptions - often not even KWin related (plasmashell hangs for corrupted cache and whatnot issues)

=> I'll now close it as WONTFIX. Please abort it completely. Do not post on it.
Not even to confirm this stance (to keep this message on top)

If you've continuing problems and believe they're related to KWin (whether as window manager or compositor), please open a NEW bug with an exact description of your problem and have us triage them.

Ruchir, I'm very sorry that this happened.
If your original problem persists, please just re-file it. Sorry again.

Changed in kdebase-workspace:
status: New → Won't Fix
Revision history for this message
In , SinClaus (tomsk-interface) wrote :

At the moment we have kwin 5.5.1, but every morning I see that my working comp hangs after screen saver is over.
"kwin_x11 --replace" reanimate comp.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

bug #353587 won't fix with any KDE release, it's a bug in XLib.
And please stop commenting on *this* bug, see comment #154

Revision history for this message
In , SinClaus (tomsk-interface) wrote :

OK, but I can't understand why this bug in XLib don't affect with KDE 4.

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

not kde4, qt4.
it's - very likely - due to combined xcb and xlib usage and on top of that happens in xinout2.
none of that used in qt4.

closing seems required. sorry.

Revision history for this message
In , Cfeck (cfeck) wrote :

*** Bug 359489 has been marked as a duplicate of this bug. ***

Revision history for this message
Muh Muhowic (ultrabla) wrote :

this bug is still prevelant in 16.04

it sickens me. kde never starts to make the DE just work.

"oh no lets port kde to $rarest_dev."

Revision history for this message
Roman Paholík (wizzardsk) wrote :

It also affects my system. Intel Core 2 Quad, nVidia GT 740, Kubuntu 16.04, Plasma 5.5.5, Qt 5.5.1, it happens a few months already, since 15.10, I think.

Revision history for this message
chris.stevens@eng.ox.ac.uk (chris-stevens-7) wrote :

I'm getting this effect to. Usually when a dialogue window pops up, or on opening a new application kwin crashes losing all the window decorations and input focus.
I generally fix it by ALT+F2 to bring up an input and then typing kwin to restart it.
It's pretty poor show that this happens. After all the window manager is a pretty vital function of the system and if we can't get that to work why should anyone bother using it,....

I'm surprised this bug still exists. My system is Kubuntu 16.04, the 64bit version.

This only started happening when I tried to change the theme on the desktop - after changing the theme kwin crashes started happening. Sadly changing back to the original theme didn't return the system to stability...honestly I think I'm off to buy a MAC. After 15 years of using Linux it seems to be getting harder, not easier...

Revision history for this message
chris.stevens@eng.ox.ac.uk (chris-stevens-7) wrote :

I've just installed kde 5.6.6 - hoping this is a fix

Revision history for this message
Woko (wolfram-koehn) wrote :

It still happens several times a day in Yakkety (kde: 5.26.0 QT: 5.6.1).

Revision history for this message
Peter Chervenski (spookey) wrote :

Yeah I also experience this several times a day, on Kubuntu 16.04. I thought it's something wrong with the GPU, but apparently this isn't the case.

Revision history for this message
Kubuntu Kjar (kubuntu-q) wrote :

I'm seeing this problem on kubuntu 14.04.5 x64 + updates (kde-window-manager 4:4.11.11-0ubuntu0.2, but also trusty-backports enabled).

It started about a month ago. It produces the "shattered windows" effect on the desktop after I unlock the screen blank from overnight. I can consistently recover by blindly typing <ALT-F2>kwin --replace<enter>.

HW is a Dell 6410 with Nvidia GT218M [NVS 3100M].

I can make more details available -- just let me know how to get them.

summary: - KWin crashes multiple times a day and often has to be restarted
- manually.
+ Who Cannot Take the Medicine?
description: updated
summary: - Who Cannot Take the Medicine?
+ KWin crashes multiple times a day and often has to be restarted
+ manually.
description: updated
Changed in kwin (Ubuntu):
status: Triaged → Won't Fix
Displaying first 40 and last 40 comments. View all 173 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.