Bug 294451 - activate/deactivate Blur effect while Show Paint effect is enabled causes Crash
Summary: activate/deactivate Blur effect while Show Paint effect is enabled causes Crash
Alias: None
Product: kwin
Classification: Unclassified
Component: compositing (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: KWin default assignee
Depends on:
Reported: 2012-02-19 21:03 UTC by abulak
Modified: 2016-11-02 13:41 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: ReviewRequest+

glxinfo dump (30.04 KB, text/plain)
2012-02-23 22:42 UTC, abulak

Note You need to log in before you can comment on or make changes to this bug.
Description abulak 2012-02-19 21:03:14 UTC
Application: kwin (4.8.00 (4.8.0)
KDE Platform Version: 4.8.00 (4.8.0 (Compiled from sources)
Qt Version: 4.7.4
Operating System: Linux 3.2.1-pf x86_64
Distribution (Platform): Gentoo Packages

-- Information about the crash:
- What I was doing when the application crashed:

As in the title.
1) enable Show paint effect
2) open Desktop effects
3) select/deselect Blur effect
4) hit Apply and watch kwin crash.

The crash can be reproduced every time.

-- Backtrace:
Application: KWin (kwin), signal: Segmentation fault
[Current thread is 1 (Thread 0x7f37bf2957a0 (LWP 3622))]

Thread 2 (Thread 0x7f37b0adb700 (LWP 3632)):
#0  0x00007f37bc70943c in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x00000036a8cdf802 in QTWTF::TCMalloc_PageHeap::scavengerThread() () from /usr/lib64/qt4/libQtScript.so.4
#2  0x00000036a8cdf85b in QTWTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib64/qt4/libQtScript.so.4
#3  0x00007f37bce242da in ?? () from /usr/lib64/libGL.so.1
#4  0x00007f37bc704ccc in start_thread () from /lib64/libpthread.so.0
#5  0x00007f37beb080bd in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f37bf2957a0 (LWP 3622)):
[KCrash Handler]
#6  0x00000036a0c2f860 in QString::shared_null () from /usr/lib64/qt4/libQtCore.so.4
#7  0x00007f37bee5f41c in KWin::EffectsHandlerImpl::buildQuads(KWin::EffectWindow*, KWin::WindowQuadList&) () from /usr/lib64/libkdeinit4_kwin.so
#8  0x00007f37bee49606 in KWin::Scene::Window::buildQuads(bool) const () from /usr/lib64/libkdeinit4_kwin.so
#9  0x00007f37bee5dadb in KWin::EffectWindowImpl::buildQuads(bool) const () from /usr/lib64/libkdeinit4_kwin.so
#10 0x00007f37bee1af37 in KWin::Shadow::updateShadow() () from /usr/lib64/libkdeinit4_kwin.so
#11 0x00007f37bee460be in KWin::Toplevel::getShadow() () from /usr/lib64/libkdeinit4_kwin.so
#12 0x00007f37bee18794 in KWin::Toplevel::propertyNotifyEvent(XPropertyEvent*) () from /usr/lib64/libkdeinit4_kwin.so
#13 0x00007f37bee187d1 in KWin::Client::propertyNotifyEvent(XPropertyEvent*) () from /usr/lib64/libkdeinit4_kwin.so
#14 0x00007f37bee19514 in KWin::Client::windowEvent(_XEvent*) () from /usr/lib64/libkdeinit4_kwin.so
#15 0x00007f37bee198ed in KWin::Workspace::workspaceEvent(_XEvent*) () from /usr/lib64/libkdeinit4_kwin.so
#16 0x00007f37bee11c6c in KWin::Application::x11EventFilter(_XEvent*) () from /usr/lib64/libkdeinit4_kwin.so
#17 0x00000036a101b3c4 in qt_x11EventFilter(_XEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#18 0x00000036a1025aed in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib64/qt4/libQtGui.so.4
#19 0x00000036a1047089 in QEventDispatcherX11::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtGui.so.4
#20 0x00000036a0909837 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#21 0x00000036a0909a14 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/qt4/libQtCore.so.4
#22 0x00000036a090c7d6 in QCoreApplication::exec() () from /usr/lib64/qt4/libQtCore.so.4
#23 0x00007f37bee13506 in kdemain () from /usr/lib64/libkdeinit4_kwin.so
#24 0x00007f37bea502ad in __libc_start_main () from /lib64/libc.so.6
#25 0x0000000000400789 in _start ()

Reported using DrKonqi
Comment 1 Thomas Lübking 2012-02-19 21:20:34 UTC
not here, but this:
#6  0x00000036a0c2f860 in QString::shared_null () from
#7  0x00007f37bee5f41c in

is a memory corruption (there's no string in that function) meaning m_currentBuildQuadsIterator is invalid.

please provide:
qdbus org.kde.kwin /KWin activeEffects
as well as
grep -iE 'kwin4_effect_.*Enabled=true' `kde4-config --path config | cut -d":" -f1`/kwinrc | sed -e 's/kwin4_effect_//g; s/Enabled=true//g'

outputs before right causing the crash.
(be aware that both are one-liners, bugzilla tends to break them in html ...)
Comment 2 abulak 2012-02-19 21:35:04 UTC
here they are:



For some reason I can't reproduce now crash during _activation_ of the Blur effect. Nevertheless I am able to reproduce it while deactivating blur with similar back-trace (or at least drkonqi thinks so)
Comment 3 Thomas Lübking 2012-02-19 21:51:14 UTC
Nope, still not (but on a 32bit installation)

How did you obtain beclock? Please try to disable it.

FTR: fade / slide & magiclamp / minimizeanimation
These effects somewhat (visually) collide.
Comment 4 abulak 2012-02-19 22:27:05 UTC
beclock from kde-look.org, compiled from source (0.16, I dealt with gles/no-gles issues by commenting in makefile everything with string gles inside);
enabling/disabling beclock changes nothing;

Ok, I spent more time experimenting:

I am now quite sure, that it has nothing to do with simultaneous activation/deactivation of effects.

Translucency, Show Paint and Blur Plugins are causing kwin crash while deactivation in all combinations of others enabled/disabled. 

So now I have just to

deactivate any one of {Blur, Show Paint, Translucency} to observe kwin crash.

a bit off-topic

At first I was just curious, why kwin consumes 50% of cpu when blurring a window, hence I enabled the show paint effect. This is another issue: kwin keeps repainting all blurred areas (windows shadows, panels, translucent windows etc. Is it normal behavior?
Comment 5 Thomas Lübking 2012-02-19 23:47:11 UTC
(In reply to comment #4)

> At first I was just curious, why kwin consumes 50% of cpu when blurring a
> window, hence I enabled the show paint effect. This is another issue: kwin
> keeps repainting all blurred areas (windows shadows, panels, translucent
> windows etc. Is it normal behavior?

It actually looks like non-opaque inactive windows with titlebars and new shadows (atm. bespin at least) cause repaint loops on the shadows - which however stop on opacity changes. Is that what you observe?
Comment 6 abulak 2012-02-20 00:10:58 UTC
When You say

> which however stop on opacity changes.

I am not quite sure what are You referring to...

When I switch to different decorations (e.g. oxygen) the repaint loop doesn't start _on decorations_. On more or less transparent panels I can still see continues repaint action. 

Bespin style decorations causes this behavior, As You said.
Comment 7 Thomas Lübking 2012-02-20 01:20:00 UTC
It comes with the shadow (pixmap) resize (downwards) - if you link active and inactive shadow size in the bespin deco config it should stop.

I know why this happens and have a patch, can you try it on your side for confirmation?
Comment 8 abulak 2012-02-20 09:13:57 UTC
Sure I can test it;

Concerning the main bug issue, it should be low priority bug, You don't switch effects on and off on a daily basis ;-)
Comment 9 Thomas Lübking 2012-02-20 15:04:37 UTC
Here you go:
Comment 10 abulak 2012-02-20 19:56:34 UTC
Ok, thanks to the portage user-patches feature it went painless.

I did kwin --restart, then restarted X.

But actually nothing has changed. Still a kaleidoscope around window borders (bespin decorations) and panels (panels were also target of the patch?)
Comment 11 Thomas Lübking 2012-02-20 20:07:46 UTC
you probably observe sth. similar but different which seems apparent with only the OpenGL backend but regardless of blurring (does it stop with the xrender backend?)

Something on your Desktop (i tried a video) will likely constantly repaint and all decorations (at least for bespin) will repaint with it. No idea why - yet.
(still, please try to confirm)
Comment 12 Thomas Lübking 2012-02-20 20:30:12 UTC
No, wrong - it /is/ related to the blur effect.
Comment 13 Thomas Lübking 2012-02-20 21:00:46 UTC
... and it's because i lie about "AbilityUsesAlphaChannel", not doing so will not cause linked repaints with blurring, but paint no decoration in the GL case at all (what is related to the usage of the new shadows) - stay tuned ;-)
Comment 14 abulak 2012-02-20 21:03:04 UTC
Hah, got it! this is actually quite unexpected:Cpu-monitor plasmoid. 

I had it set to update every 0.2s -> whole panel got repaited->everything
blurred got repainted every 0.2s. Removed it and everything is normal now.

We have a solution, and the cause, now where is the causation? ;-)

On the other hand now I see, that krunner makes all panels repaint in the rythm
of blinking cursor.

More experiments:

Beclock repaints only itself _unless_ it covers shadow of another window. Then
again all blurred areas are repainted every time beclock changes (every 1s

Mouse movement/copying files/any changes to panel causes whole blurred area to

With XRender blur gets disabled so I can't reproduce this behavior. But with
blur disabled I see that kwin can repaint only part of panel (like
notifications, etc). This indicates that with enabled blur any change to simple
element (like blinking cursor above) causes whole panel area to repaint.

hope this was helpful.
Comment 15 Thomas Lübking 2012-02-21 00:11:14 UTC
Regarding the decoration:
If you make AbilityUsesAlphaChannel return true in bespin/kwin/factory.cpp this behaviour should go away (no direct idea about the panel though) - unfortunately you'll also get an empty decoration / titlebar.

The reason is that with the "decoration" expanded by the shadows a line in kde-workspace/kwin/scene.cpp and function WindowQuadList Scene::Window::buildQuads(bool force) const (~ line 586, my version probably differs) becomes wrong

        QRegion center = toplevel->transparentRect();
-        QRegion decoration = (client && Workspace::self()->decorationHasAlpha() ?
                              QRegion(client->decorationRect()) : shape()) - center;
        ret = makeQuads(WindowQuadContents, contents);
        if (!client || !(center.isEmpty() || client->isShade()))

        QRegion center = toplevel->transparentRect();
+        QRegion decoration = shape() - center;
        ret = makeQuads(WindowQuadContents, contents);
        if (!client || !(center.isEmpty() || client->isShade()))

I'm however atm. not entirely sure whether this is a 100% correct patch (looks like, though)
Comment 16 abulak 2012-02-21 21:55:28 UTC
ok, I tried the patch (the one fore scene.cpp, since I like the decorations), but I actually see no difference... what was it inteded to change?

Beclock repaints only itself, unless a window shadow (that is a blurred area) gets overlapped by it. then all blurred areas get repainted.

btw: More symptoms:
startup feedback causes all blurred areas repaint which slows down the start of an application considerably.

Also moving window on empty desktop is fast, whereas in front of blurred area (like another window) is horribly slow. The cause is the same -- When blurred area is 'damaged', kwin constantly repaints everything.
Comment 17 Thomas Lübking 2012-02-21 22:07:03 UTC
The patch against kwin does NOTHING by itself but only prevents the bespin decoration from being transparent when providing AbilityUsesAlphaChannel which should prevent a linked repaint of at least all decorations and possibly everything with any screen update. Bespin patch (can't commit w/o a fix in kwin)

Index: factory.cpp
--- factory.cpp (Revision 1466)
+++ factory.cpp (Arbeitskopie)
@@ -711,14 +711,12 @@
         return true;
     // composite
-#if KDE_IS_VERSION(4,3,0)
-    case AbilityUsesAlphaChannel: /// don't clip - it's expensive with composition
+    case AbilityUsesAlphaChannel:
+        return true;
+//     case AbilityUsesAlphaChannel: /// don't clip - it's expensive with composition
     case AbilityProvidesShadow: /// rather not
-#if KDE_IS_VERSION(4,4,0)
     case AbilityExtendIntoClientArea: /// i don't even know what this is :-)
     case AbilityClientGrouping: /// errr - NO
     case AbilityColorButtonFore: ///< decoration supports button foreground color
     case AbilityColorFrame: ///< decoration supports frame color
     case AbilityButtonResize: ///< decoration supports a resize button
Comment 18 abulak 2012-02-21 23:27:19 UTC
After patching bespin nad full restart of the system I still see no difference. All shadows of bespin decorations are still repainted.

I am not an active programmer and I don't know the kwin architecture, so I really can't help...
Comment 19 Thomas Lübking 2012-02-22 05:42:29 UTC
(In reply to comment #18)

> All shadows of bespin decorations are still repainted.

triggered by some valid constant repaint or autmatically?

> I am not an active programmer and I don't know the kwin architecture, so I
> really can't help...

Can you make a video of what you observe? (using recordmydesktop or your cell phone,in doubt - doesn't have to be long, just show the deco/shadow repaints)
Comment 20 abulak 2012-02-22 06:43:27 UTC
here it is:


in the first part You see the interaction of beclock and window shadows;
in the second the mentioned interaction of a blinking cursor and krunner
Comment 21 Thomas Lübking 2012-02-23 07:08:31 UTC
a) beclck seems to kinda superimpose
   - what kind of GPU/Driver is that?
   - does it happen w/o blurring as well?

b) does any repaint crossing the window decoration/shadows (eg. a video, blinking cursor etc.) cause such general repaint of deco/shadows/panels (ie. probably just anything ARGB) or only beclock repaints? In case: is the stacking relevant (above/below)
Comment 22 abulak 2012-02-23 17:08:08 UTC
- an old GeForce 6150SE on nvidia-drivers-290.10
- it doesn't happen without blurring.

b) Ok, You have seen effect with beclock enabled. Now I disabled beclock -- global repaints are caused by e.g. bouncing cursor _touching panel_, sliding popups while hovering over tray, taskbar, etc.

But it must touch _panel_. eg. playing video doesn't cause panel to repaint. But it causes repaint of all shadows of touching (overlapping, or underlapping) windows.
Comment 23 Thomas Lübking 2012-02-23 19:48:46 UTC
(In reply to comment #22)
> a)
> - an old GeForce 6150SE on nvidia-drivers-290.10
> - it doesn't happen without blurring.

That's some mobile chip, isn't?
-> Is that with or without OpenGL2 shaders enabled?
Please also attach a dump of glxinfo.
Comment 24 abulak 2012-02-23 22:42:41 UTC
Created attachment 69045 [details]
glxinfo dump
Comment 25 abulak 2012-02-23 22:43:18 UTC
Yes, it is mobile IGP chip.

Wikipedia claims OpenGL2.1 compatibility.
Comment 26 Thomas Lübking 2012-02-24 21:42:57 UTC
(In reply to comment #25)
> Yes, it is mobile IGP chip.
> Wikipedia claims OpenGL2.1 compatibility.

Should be the first generation to support GLSL in KWin, but:
 is "Use OpenGL2 shaders" checked?
Does the clock still superimpose if it's not checked?

Regarding having successfully attempted the latest kwin patch: if you have, bespin decoration works as expected, but oxygen shadows are broken. (not painted at all) - confirmed?
Comment 27 abulak 2012-02-25 09:28:46 UTC
Yes, Use OpenGL2 shaders is checked;

I don't know what You mean by superimpose, but I see no difference in beclock with or without OpenGL2 shaders enabled.

Oxygen decoration doesn't paint its shadows - confirmed. But bespin shadows are still visible regardless of window decoration selected
Comment 28 Thomas Lübking 2012-02-25 14:18:29 UTC
In the video it looks like the clock gets painted several times on top of each other before the region is cleared - that is NOT an expected behavior.

I guess repaint behavior won't change depending on the GLSL usage either then?!

Other decos than oxygen do not withdraw present shadows - i've to check whether i can identify when decorations are destroyed because the decoration was changed to get those away myself.
Comment 29 abulak 2012-03-01 16:28:15 UTC
OK, I'm sorry for delay, but I was quite sure I did answered to Your last post ;/

You may disregard the appearance of beclock on the video. It looks perfectly fine here. I guess this is related to the fact that recordmydesktop doesn't catch all the frames.

No, repaint behavior doesn't change no matter OpenGL2 shaders are used or not.
Comment 30 abulak 2012-04-16 09:29:28 UTC
Just a markup:

in Kwin-4.8.2 I can still reproduce the initial bug, namely:

kwin crashes while disabling Blur/ShowPaint effects.

However in 4.8.2 (or in 4.8.1??) the mentioned above repaint behaviour is gone (I haven't updated bespin recently, how can I check its version?)
Comment 31 Thomas Lübking 2012-05-07 20:38:04 UTC
possibly dupe of bug #299582
Comment 32 Martin Flöser 2013-01-18 19:42:17 UTC
I set it to duplicate of #299582. If you are still able to reproduce with 4.9 or later, please reopen.

*** This bug has been marked as a duplicate of bug 299582 ***
Comment 33 abulak 2013-01-18 22:13:30 UTC
Gentoo (unstable)

I can still reproduce it.
Comment 34 Thomas Lübking 2013-01-18 22:56:31 UTC
Re-opening because dupe is not reproducible by reporter and different triggers are invoked.
Comment 35 Martin Flöser 2016-11-02 13:41:52 UTC
The crash was reported against a 4.x version and is unfortunately lacking debug symbols. This makes it close to impossible to further try to investigate the issue. To many things have changed in 5.x - especially concerning the handling of updating the shadow and building the quads after updating the shadow.