not here, but this:
#6  0x00000036a0c2f860 in QString::shared_null () from
/usr/lib64/qt4/libQtCore.so.4
#7  0x00007f37bee5f41c in
KWin::EffectsHandlerImpl::buildQuads(KWin::EffectWindow*,

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 ...)

here they are:

kwin4_effect_showpaint
kwin4_effect_translucency
kwin4_effect_blur
kwin4_effect_beclock

beclock
blur
dashboard
desktopgrid
dimscreen
fade
highlightwindow
login
logout
magiclamp
minimizeanimation
outline
presentwindows
scalein
sheet
showpaint
slide
slideback
slidingpopups
startupfeedback
translucency
wobblywindows

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)

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.

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?

(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?

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.

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?

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 ;-)

Here you go:
https://git.reviewboard.kde.org/r/104028/

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?)

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)

No, wrong - it /is/ related to the blur effect.

... 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 ;-)

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
here).

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

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.

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)

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.

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
-#endif
-#endif
     case AbilityColorButtonFore: ///< decoration supports button foreground color
     case AbilityColorFrame: ///< decoration supports frame color
     case AbilityButtonResize: ///< decoration supports a resize button

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...

(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)

here it is:

http://dl.dropbox.com/u/2158899/out.ogv

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

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)

a)
- 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.

(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.

Created attachment 69045 [details]
glxinfo dump

Yes, it is mobile IGP chip.

Wikipedia claims OpenGL2.1 compatibility.

(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?

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

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.

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.

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?)

possibly dupe of bug #299582
http://git.reviewboard.kde.org/r/104881/

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 ***

Gentoo (unstable)
kwin-4.9.5

I can still reproduce it.

Re-opening because dupe is not reproducible by reporter and different triggers are invoked.

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.