#12 0x00007f6c7cff6828 in KWindowSystem::icon(unsigned long long, int, int, bool, int) () from /usr/lib/libKF5WindowSystem.so.5
// KXIUtils::createPixmapFromHandle(WId pixmap, WId pixmap_mask)
#11 0x00007f6c7d0026f9 in ?? () from /usr/lib/libKF5WindowSystem.so.5
// KXUtils::fromNative(xcb_pixmap_t pixmap)
#10 0x00007f6c7cffb2ac in ?? () from /usr/lib/libKF5WindowSystem.so.5
#9  0x00007f6c7842a9bf in QPixmap::setMask(QBitmap const&) () from /usr/lib/libQt5Gui.so.5
#8  0x00007f6c783fe8d7 in QImage::scanLine(int) () from /usr/lib/libQt5Gui.so.5

even if the image wasNull(), detaching it should rather not crash
#7  0x00007f6c783fe78c in QImage::detach() () from /usr/lib/libQt5Gui.so.5
#6  0x00007f6c783fdc93 in QImage::copy(QRect const&) const () from /usr/lib/libQt5Gui.so.5
#5  0x00007f6c80035850 in __memcpy_sse2_unaligned () from /usr/lib/libc.so.6

What could happen is that the conversion "fails" and creates a HUUUUUUUUGE image -> OOM?

How does memory usage behave when this happens?

Didn't notice any memory issues.

I also can't seem to reproduce it any more after a restart, so I'm not sure why it was segfaulting before.

@Martin
worksforme or not - somthing looks fishy here.

KX11Utils::fromNative(xcb_pixmap_t pixmap) creates a QImage on the data of xcb_get_image_reply() which itself lives in a scoped pointer.

Obviously, that data is gone when ::setMask attempts to detach the pixmap.

The image is detached in ::fromImage(), but this does NOT happen if Q_COMPILER_RVALUE_REFS is defined! (calling internal ::fromImageInPlace())

To me this smells as if we'd have to explicitly copy the data (in this case)?

> To me this smells as if we'd have to explicitly copy the data (in this
> case)?

That's quite possible. What makes me wonder is why we haven't had a problem so 
far. There must be some other factor which triggers it (and which I'd like to 
know to unit test it).

(In reply to Martin Gräßlin from comment #4)
> > To me this smells as if we'd have to explicitly copy the data (in this
> > case)?
> 
> That's quite possible. What makes me wonder is why we haven't had a problem
> so far.

That icon source will be used rather seldom (majority of clients has _NET_WM_ICON) and if there's (usually? - even xterm has) a mask, and despite triggering the crash here, we immediately detach a copy afterwards, so there's only a "brief moment" where the invalidated data is in use.

I don't claim that this sufficiently explains it ("fishy", not "buggy"), but chances to run into this segfault (w/o glib compiled to abort on and detect this case) are rather low.

Not sure whether we can even (easily) debug this, since QPixmap does not publish the internal data (":bits()"; will test whether ::toImage() *might* preserve this)

I'm getting a very similar segfault when starting Kodi (former XBMC) on plasma 5.1.1.
Here is the backtrace:

#0  0x00007ffff60d459b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1  0x00007ffff60d72ac in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#2  0x00007ffff5f1c099 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#3  0x00007ffff5f1c90a in QImage::transformed(QTransform const&, Qt::TransformationMode) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#4  0x00007ffff5f1d348 in QImage::scaled(QSize const&, Qt::AspectRatioMode, Qt::TransformationMode) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#5  0x00007ffff6f9e4a5 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5
#6  0x00007ffff6f94bd8 in KWindowSystem::icon(unsigned long long, int, int, bool, int) () from /usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5
#7  0x00007ffff74605ce in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#8  0x00007ffff7499319 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#9  0x00007ffff744945d in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#10 0x00007ffff74898af in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#11 0x00007ffff598a420 in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007fffe174caa8 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#13 0x00007fffe174df1b in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#14 0x00007ffff59bd12a in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff665f16c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007ffff666441e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00007ffff598d81b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff598f7e3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x00007ffff59e2422 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007fffe179e7dd in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#21 0x00007ffff598b042 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x00007ffff5992acc in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007ffff7bd7913 in kdemain () from /usr/lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so
#24 0x00007ffff782fec5 in __libc_start_main (main=0x4007d0 <main>, argc=1, argv=0x7fffffffe828, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffe818) at libc-start.c:287
#25 0x00000000004007fe in _start ()

Reproducible?

Does your distro provide debug enabled libraries (w/ line numbers etc.)?
https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports

Can you compile and run a patch (to the "kwindowsystem" frameworks module)?

My distro is Kubuntu. I've installed libkf5windowsystem5-dbg, but there is no a dbg package for the libqt5gui5 package (I assume libQt5Gui.so.5 is from this package). Please find the stack below.

Yes, I can rebuild the package (libkf5windowsystem5 ?) with a patch applied if you provide me the patch.

Here is the backtrace:

Thread 1 (Thread 0x7f721b090800 (LWP 15044)):
[KCrash Handler]
#5  0x00007f72191cd59b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#6  0x00007f72191d02ac in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x00007f7219015099 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#8  0x00007f721901590a in QImage::transformed(QTransform const&, Qt::TransformationMode) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x00007f7219016348 in QImage::scaled(QSize const&, Qt::AspectRatioMode, Qt::TransformationMode) const () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#10 0x00007f721a0974a5 in scaled (mode=<optimized out>, aspectMode=<optimized out>, h=<optimized out>, w=<optimized out>, this=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtGui/qimage.h:251
#11 KWindowSystemPrivateX11::icon (this=0x7f71f3549030, win=83886082, width=16, height=0, scale=false, flags=3) at ../../src/kwindowsystem_x11.cpp:689
#12 0x00007f721a08dbd8 in KWindowSystem::icon (win=83886082, width=16, height=16, scale=<optimized out>, flags=3) at ../../src/kwindowsystem.cpp:466
#13 0x00007f721a5595ce in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#14 0x00007f721a592319 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#15 0x00007f721a54245d in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#16 0x00007f721a545a66 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#17 0x00007f721a546575 in ?? () from /usr/lib/x86_64-linux-gnu/libkwin.so.5
#18 0x00007f721accfae6 in ?? () from /usr/lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so
#19 0x00007f7218ab4d7e in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x00007f721a08e802 in KSelectionOwner::Private::claimSucceeded (this=0x1ae4ec0) at ../../src/kselectionowner.cpp:180
#21 0x00007f721a08efd1 in KSelectionOwner::filterEvent (this=0x1ae0f10, ev_P=<optimized out>) at ../../src/kselectionowner.cpp:398
#22 0x00007f7218a83420 in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#23 0x00007f7204845aa8 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#24 0x00007f7204846f1b in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#25 0x00007f7218ab612a in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x00007f721975816c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#27 0x00007f721975d41e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#28 0x00007f7218a8681b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007f7218a887e3 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x00007f7218adb422 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x00007f72048977dd in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#32 0x00007f7218a84042 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007f7218a8bacc in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007f721acd0913 in kdemain () from /usr/lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so
#35 0x00007f721a928ec5 in __libc_start_main (main=0x4007d0 <main>, argc=3, argv=0x7fffdae7bcf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffdae7bce8) at libc-start.c:287
#36 0x00000000004007fe in _start ()

kwindowsystem would be the module to rebuild, yes.
Please first ensure that your vanilla recompile triggers the same crash (could be debug build/optimization related!)

This patch then should hopefully do:

diff --git a/src/kxutils.cpp b/src/kxutils.cpp
index 44885e0..09fa423 100644
--- a/src/kxutils.cpp
+++ b/src/kxutils.cpp
@@ -119,6 +119,7 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
         if (image.isNull()) {
             return T();
         }
+        image.detach(); // on rvalue support, QPixmap/raster will invoke fromImageInPlace, ie. reuse the xImage data
         return T::fromImage(image);
     }
     case 32:
@@ -146,6 +147,7 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
         image.setColor(0, QColor(Qt::white).rgb());
         image.setColor(1, QColor(Qt::black).rgb());
     }
+    image.detach(); // on rvalue support, QPixmap/raster will invoke fromImageInPlace, ie. reuse the xImage data
     return T::fromImage(image);
 }

I've applied the patch, but unfortunately nothing changed.

The let's be more convincing ;-)
(Ok, the truth is, that the detach is NOOP to a so far not shared image)

diff --git a/src/kxutils.cpp b/src/kxutils.cpp
index 44885e0..3157c39 100644
--- a/src/kxutils.cpp
+++ b/src/kxutils.cpp
@@ -119,7 +119,9 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
         if (image.isNull()) {
             return T();
         }
-        return T::fromImage(image);
+        QImage img2 = image;
+        img2.detach();
+        return T::fromImage(img2);
     }
     case 32:
         format = QImage::Format_ARGB32_Premultiplied;
@@ -146,7 +148,9 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
         image.setColor(0, QColor(Qt::white).rgb());
         image.setColor(1, QColor(Qt::black).rgb());
     }
-    return T::fromImage(image);
+    QImage img2 = image;
+    img2.detach();
+    return T::fromImage(img2);
 }
 
 // Create QPixmap from X pixmap. Take care of different depths if needed.

Much better now!
Thanks, Thomas, it works!

Martin, I don't want to copy the image data ;-)

Would you be ok with the QImage constructor that takes a cleanup function/info, pass it the xImage pointer (as info parameter for a free call), taken from the scoped pointer,

Sth. along:
QImage image(xcb_get_image_data(xImage.data()), geo->width, geo->height,
                 xcb_get_image_data_length(xImage.data()) / geo->height, format,
                 freeXcbImage,  xImage.take());

should work

Much fun testing ;-)
xterm uses this icon - i figured the depth is 24bit, that's *certainly* not premultiplied.
Using rgb32 should fix the color bug someone reported.


diff --git a/src/kxutils.cpp b/src/kxutils.cpp
index 44885e0..ba41e8b 100644
--- a/src/kxutils.cpp
+++ b/src/kxutils.cpp
@@ -30,6 +30,12 @@
 namespace KXUtils
 {
 
+static void freeXcbImage(void *xcbImage)
+{
+    free(reinterpret_cast<xcb_get_image_reply_t*>(xcbImage));
+}
+
+
 static uint8_t defaultDepth()
 {
     xcb_connection_t *c = QX11Info::connection();
@@ -104,22 +110,20 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
     case 1:
         format = QImage::Format_MonoLSB;
         break;
+    case 24:
+        format = QImage::QImage::Format_RGB32;
+        break;
     case 30: {
         // Qt doesn't have a matching image format. We need to convert manually
         uint32_t *pixels = reinterpret_cast<uint32_t *>(xcb_get_image_data(xImage.data()));
-        for (int i = 0; i < xImage.data()->length; ++i) {
+        for (uint i = 0; i < xImage.data()->length; ++i) {
             int r = (pixels[i] >> 22) & 0xff;
             int g = (pixels[i] >> 12) & 0xff;
             int b = (pixels[i] >>  2) & 0xff;
 
             pixels[i] = qRgba(r, g, b, 0xff);
         }
-        QImage image(reinterpret_cast<uchar *>(pixels), geo->width, geo->height,
-                     xcb_get_image_data_length(xImage.data()) / geo->height, QImage::Format_ARGB32_Premultiplied);
-        if (image.isNull()) {
-            return T();
-        }
-        return T::fromImage(image);
+        // fall through, Qt format is still Format_ARGB32_Premultiplied
     }
     case 32:
         format = QImage::Format_ARGB32_Premultiplied;
@@ -136,7 +140,8 @@ template <typename T> T fromNative(xcb_pixmap_t pixmap)
         }
     }
     QImage image(xcb_get_image_data(xImage.data()), geo->width, geo->height,
-                 xcb_get_image_data_length(xImage.data()) / geo->height, format);
+                 xcb_get_image_data_length(xImage.data()) / geo->height, format, freeXcbImage, xImage.data());
+    xImage.take();
     if (image.isNull()) {
         return T();
     }

Same problem with my setup.  XBMC always crashes kwin.
Any solution in master is available yet ?

Thanks for the help !

The bug will be closed (and all CC's get mails) as soon as the patch is pushed after being approved.

(In reply to Thomas Lübking from comment #17)
> The bug will be closed (and all CC's get mails) as soon as the patch is
> pushed after being approved.

Thank for the info. I am a Kodi developer and just fooling around with the new Plasma 5 and have to tell that I fell in love with it. Just what I miss is to actually run Kodi on it. 
Could you please give me some help how to compile with the patch, so I can give you a feedback ? As I get from previous comments I have to compile the kwindowsystem module. I have stuck with a cmake error:
CMake Error at /usr/share/ECM/modules/ECMPackageConfigHelpers.cmake:84 (file)
Any ideas ? Thanks

I can share patched Ubuntu package kwindowsystem_5.3.0~git20141002.

(In reply to Andrey from comment #19)
> I can share patched Ubuntu package kwindowsystem_5.3.0~git20141002.

Would be awesome :-)
Much appreciated.

> CMake Error at /usr/share/ECM/modules/ECMPackageConfigHelpers.cmake:84 (file)
The CMake error is hopefully longer, but you might lack or only have a "dated" version of "extra-cmake-modules"?

To prevent kodi from running into this bug, it would just have to support the _NET_WM_ICON property[1] - the crash is in the legacy icon support (that's probably also why it went unnoticed, it's called only for very few clients - and then still have to trigger some memory invalidation)


[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472568384

Created attachment 89667 [details]
kwindowsystem_patched.zip

Please find the patched packages attached.

Thanks guys, you are awesome.
I was not aware that Kodi uses a legacy icon. Will report it to the team and  make sure to change this over.

Regards,
Attila

I'm having this same issue running:

laptop➜  ~  ᐅ  kwin_x11 --version
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-erratic'
kwin 5.1.90
 this is compiled from git, I just ran smart-live-rebuild on it so it has to be the latest kwin_x11 and its still having this problem. Funny how emerge --info gives so much information but doesn't provide the SHA hash of the commit / branch that a package was built from:

[ebuild   R   *] kde-base/kwin-9999:5::kde  USE="-debug -gles2 -handbook {-test} -wayland" 0 kB
but after further inspection I believe it is built from:
50cbe810f5815403fed66c854a0c12d32b139af2                git://anongit.kde.org/kwin

so if this problem has been "fixed" in any recent commits it's still broken or the issue isn't related to kwin.

(In reply to Paige Thompson from comment #25)
> I'm having this same issue running:
> 
> laptop➜  ~  ᐅ  kwin_x11 --version
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-erratic'
> kwin 5.1.90
>  this is compiled from git, I just ran smart-live-rebuild on it so it has to
> be the latest kwin_x11 and its still having this problem. Funny how emerge
> --info gives so much information but doesn't provide the SHA hash of the
> commit / branch that a package was built from:
> 
> [ebuild   R   *] kde-base/kwin-9999:5::kde  USE="-debug -gles2 -handbook
> {-test} -wayland" 0 kB
> but after further inspection I believe it is built from:
> 50cbe810f5815403fed66c854a0c12d32b139af2               
> git://anongit.kde.org/kwin
> 
> so if this problem has been "fixed" in any recent commits it's still broken
> or the issue isn't related to kwin.

Also I should point out with regards to my last comment, that I am able to run xbmc in xfce just fine both full screen and windowed

(In reply to Paige Thompson from comment #25)
> so if this problem has been "fixed" in any recent commits it's still broken
> or the issue isn't related to kwin.

The moment the liked patch gets pushed upstream, this bug will be closed.

It's actually not related to kwin, but the kwindowsystem library in frameworks.
Any process trying to access this kind of icon through it will suffer from the bug.

Comment on attachment 89667 [details]
kwindowsystem_patched.zip

RIP 

laptop➜  Downloads  ᐅ  unzip kwindowsystem_patched.zip
Archive:  kwindowsystem_patched.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of kwindowsystem_patched.zip or
        kwindowsystem_patched.zip.zip, and cannot find kwindowsystem_patched.zip.ZIP, period.
laptop➜  Downloads  ᐅ

laptop➜  Downloads  ᐅ  file kwindowsystem_patched.zip
kwindowsystem_patched.zip: gzip compressed data, last modified: Fri Nov 21 16:52:10 2014, from Unix
laptop➜  Downloads  ᐅ  cat kwindowsystem_patched.zip | gunzip - > weird
laptop➜  Downloads  ᐅ  file weird
weird: POSIX tar archive
laptop➜  Downloads  ᐅ

laptop➜  Downloads  ᐅ  tar -xvf weird
kwindowsystem_patched/
kwindowsystem_patched/libkf5windowsystem-dev_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1_amd64.deb
kwindowsystem_patched/libkf5windowsystem5-dbg_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1_amd64.deb
kwindowsystem_patched/kwindowsystem_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1.debian.tar.xz
kwindowsystem_patched/libkf5windowsystem5_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1_amd64.deb
kwindowsystem_patched/kwindowsystem_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1.dsc
kwindowsystem_patched/kwindowsystem_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1_amd64.changes
kwindowsystem_patched/kwindowsystem_5.3.0~git20141002.orig.tar.gz
kwindowsystem_patched/libkf5windowsystem-data_5.3.0~git20141002-0ubuntu1~ubuntu14.10~ppa1_all.deb
laptop➜  Downloads  ᐅ

Ya I am so not running those on my computer anyway-- assuming this fix is a fix will it be in revision control, ie: 
laptop kwin.git # cat FETCH_HEAD
50cbe810f5815403fed66c854a0c12d32b139af2                git://anongit.kde.org/kwin
laptop kwin.git #

anytime soon assuming its not already?
Please contact me and let me know, 

Thanks, 
-Paige

(In reply to Paige Thompson from comment #28)
> laptop➜  Downloads  ᐅ  unzip kwindowsystem_patched.zip
Please notice that this is a binary provided by one user for another.
The patch is here (url link on this bug):
https://git.reviewboard.kde.org/r/121158/

> fix will it be in revision control, ie: 
> laptop kwin.git # cat FETCH_HEAD

No! It's not a patch for KWin.
This repo:
git://anongit.kde.org/kwindowsystem.git

> 50cbe810f5815403fed66c854a0c12d32b139af2               

> anytime soon assuming its not already?
It's not and I cannot predict when it will.

Also another thing I just figured out: 

switched to a VC, ran startx which gave me another xserver (ctrl-alt-f8 next to f7) didn't even know you could do that, anyway in TWM ran xbmc and got this: 

[oh-my-zsh] Random theme '/home/erratic/.oh-my-zsh/themes/frisk.zsh-theme' loaded...

/home/erratic [erratic@laptop] [0:05]
> xbmc
WARNING: running kodi as xbmc is deprecated and will be removed in later versions, please switch to using the kodi binary
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
/usr/bin/xbmc: line 168:  2379 Killed                  (core dumped) "$LIBDIR/${bin_name}/${bin_name}.bin" $SAVED_ARGS

/home/erratic [erratic@laptop] [0:05]
>

from kernel
[508422.151228] PAX: execution attempt in: <anonymous mapping>, 2d6e400e000-2d6e410e000 2d6e400e000
[508422.151232] PAX: terminating task: /usr/lib64/kodi/kodi.bin(kodi.bin):2379, uid/euid: 1000/1000, PC: 000002d6e400e140, SP: 00000398a83614e8
[508422.151234] PAX: bytes at PC: 55 41 57 41 56 41 55 41 54 53 48 81 ec a8 02 00 00 44 89 44
[508422.151248] PAX: bytes at SP-8: 0000000000000003 000002d6e81989bc 0000000defc03888 0000000d00000000 0000000d00000000 0000000defd884b0 0000000defd8d520 0000000d00000004 0000000000000000 000002d6e6d8035b 0000000df0132bb0
╭─erratic@laptop  ~
╰─$


Not sure what this says for kwin but I sure would like to be able to do this since kwin can't play nice with xbmc at the moment.

Also I checked the settings for the compositor (in the kde control panel and it's not even enabled (cube got real slow after switching to PaX / grsec so I turned all that stuff off.) I want to say its strange that libgl can't lock drm since it seems to have no problem doing this in xfce.

honestly, I had to soften everything quite a bit to get kde to run on here: 
╭─erratic@laptop  ~
╰─$
╭─erratic@laptop  ~
╰─$ cat /etc/fix_broken_executables.sh                                                                                                                                                                                                                             1 ↵
#!/bin/bash

paxctl -pemrxs /usr/bin/ksplashqml
paxctl -pemrxs /usr/bin/kwin_x11
paxctl -pemrxs /usr/bin/krunner
paxctl -pemrxs /usr/bin/plasmashell
paxctl -pemrxs /usr/bin/systemsettings5
paxctl -pemrxs /usr/bin/kate
# /usr/bin/kdeinit5
╭─erratic@laptop  ~
╰─$

-pemrxs might have been a little over the top but I just wanted to get kde working again. I hope somebody at some point takes things like this into account and fixes them.

Ah interesting, I was able to proceed with the above solution of running two X11 servers, I just had to run xbmc as root (drm permissions, wish I could find a better solution.) At any rate this seems to work fine for now and kwin isn't crashing

(In reply to Paige Thompson from comment #30)
> Also another thing I just figured out: 
Please notice that this is a bugtracker and not a mailing list.
If you think, you encountered some bug, please file it instead of hijacking another one.
If you need general help, please approach forum.kde.org or (in this case) mail to kwin@kde.org
Thanks.

> libGL error: failed to open drm device: Permission denied
You started X11 as a user that has is not in the video group (or lacks other permissions, depending on your hardening). Thus no DRM permissions.
This has nothing to do with kwin or xbmc.
You should also be able to start another session (via the desktop manager) from inside the KDE session which should not have this problem (while I frankly don't know about "plasma-next" in this regard)

> since kwin can't play nice with xbmc at the moment.
As workaround, a KWin rule (kcmshell5 kwinrules) for xbmc to be forcefully undecorated should likely do.

Ah, to follow up even more on my last comment, I can totally run two X11 servers one of which runs xbmc and the other runs KDE just fine. All I needed to do was add my user to the video group, this is namely the reason I use xdm/lightdm is so I don't have to mess with stuff like that but hey, works fine now.

On 11/29/14 00:37, Thomas Lübking wrote:
> https://bugs.kde.org/show_bug.cgi?id=337626
>
> --- Comment #32 from Thomas Lübking <thomas.luebking@gmail.com> ---
> (In reply to Paige Thompson from comment #30)
>> Also another thing I just figured out: 
> Please notice that this is a bugtracker and not a mailing list.
> If you think, you encountered some bug, please file it instead of hijacking
> another one.
> If you need general help, please approach forum.kde.org or (in this case) mail
> to kwin@kde.org
> Thanks.
>
>> libGL error: failed to open drm device: Permission denied
> You started X11 as a user that has is not in the video group (or lacks other
> permissions, depending on your hardening). Thus no DRM permissions.
> This has nothing to do with kwin or xbmc.
> You should also be able to start another session (via the desktop manager) from
> inside the KDE session which should not have this problem (while I frankly
> don't know about "plasma-next" in this regard)
>
>> since kwin can't play nice with xbmc at the moment.
> As workaround, a KWin rule (kcmshell5 kwinrules) for xbmc to be forcefully
> undecorated should likely do.
>
I actually found that just running two X11 sessions and switching
between them with ctrl-alt-f7/f8 works fine, I just needed to add my
user to the video groups to get xbmc to start. I'm using both KDE and
xbmc together in this manner just fine for now.

Git commit 9dbb47b07d4b4ec1e3e46098f955d36a318794bb by Thomas Lübking.
Committed on 17/11/2014 at 19:06.
Pushed by luebking into branch 'master'.

ensure to keep image data alive w/ the image

raster QPixmaps re-use the image data (implicitly shared)
deleting them w/ scope will thus cause invalidated
memory in the returned pixmap
REVIEW: 121158

M  +4    -8    src/kxutils.cpp

http://commits.kde.org/kwindowsystem/9dbb47b07d4b4ec1e3e46098f955d36a318794bb

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

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

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