Hi all, I'm trying to start kwin_wayland on my system, but it gets stuck in a loop (at least as far as I can understand) and it requires a kill -9 to stop it. It happens starting kwin_wayland --xwayland on a konsole shell, using sddm wayland choice or starting with startplasmacompositor. Under konsole, after several seconds a black window appears and CPU usage skyrockets. trying to start kwrite using wayland, it gives no errors, simply leads to no results and a ctrl-c is required to stop it. strace shows only an infinite sequence of poll calls. weston starts just fine. environment: kwin 5.9.0 qt 5.7.1 gentoo If you need more details, debug info or else, just let me know.
As you are a gentoo user: * are you using logind? * did you run export $(dbus-launch) prior to start kwin_wayland?
1) I'm using systemd: ps ax | grep login 2552 ? Ss 0:00 /usr/lib/systemd/systemd-logind 2) Yep, I ran the line you described; moreover, the behaviour is the same if from sddm I pick the "plasma-wayland" option
good, good. Then for the moment I have no idea why it fails. If you are able to, please try to gdb into the broken kwin and get a backtrace. Best solution to do that is ssh.
Ok, I'll try to collect a trace, maybe recompiling it with debug options :) Please note that kwin_wayland is not crashed, it is simply polling in a infinite loop, kind of 4333 poll(0x7d7860003390, 3, 25044) = 1 ([0x7d7860003390]) 4333 poll(0x7d7860003390, 3, 25044) = 1 ([0x7d7860003390]) 4333 poll(0x7d7860003390, 3, 25044) = 1 ([0x7d7860003390]) 4333 poll(0x7d7860003390, 3, 25044) = 1 ([0x7d7860003390])
While configuring kwin to be compiled with debug info, I noticed that for some forgotten reason kwin was compiled with clang and not with gcc. Recompiling it with gcc 5.4.0 made the trick and now kwin_wayland works as expected (ok, with the expected issues :) ) even (somewhat) on two screens. I don't know the level of support of clang that kde offers, if "none", just disregard this bug report; otherwise I can provide more info, of course. Thanks and sorry for the noise.
Officially we require GCC, but if clang creates such an issue it might indicate a problem GCC just didn't find.
I just poked around a little bit; not really sure if this can help (probably it will take more time to have useful debug data); however if I run kwin_wayland (clang) under gdb, every time I stop it while stuck i get this backtrace: #0 0x00007ffff19e7f6f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007ffff016c5fb in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib64/libQt5Core.so.5 #2 0x00007ffff41a3824 in ?? () from /usr/lib64/libQt5DBus.so.5 #3 0x00007ffff41816e3 in ?? () from /usr/lib64/libQt5DBus.so.5 #4 0x00007ffff417898b in QDBusConnection::call(QDBusMessage const&, QDBus::CallMode, int) const () from /usr/lib64/libQt5DBus.so.5 #5 0x00007ffff41890b2 in QDBusAbstractInterface::callWithArgumentList(QDBus::CallMode, QString const&, QList<QVariant> const&) () from /usr/lib64/libQt5DBus.so.5 #6 0x00007ffff4189ace in QDBusAbstractInterface::call(QDBus::CallMode, QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&) () from /usr/lib64/libQt5DBus.so.5 #7 0x00007ffff4189bc1 in QDBusAbstractInterface::call(QString const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&, QVariant const&) () from /usr/lib64/libQt5DBus.so.5 #8 0x00007ffff4177c48 in QDBusConnectionInterface::registerService(QString const&, QDBusConnectionInterface::ServiceQueueOptions, QDBusConnectionInterface::ServiceReplacementOptions) () from /usr/lib64/libQt5DBus.so.5 #9 0x00007ffff4177e49 in QDBusConnection::registerService(QString const&) () from /usr/lib64/libQt5DBus.so.5 #10 0x00007ffff6d5ac48 in KGlobalAccelD::init() () from /usr/lib64/libKF5GlobalAccelPrivate.so.5 #11 0x00007ffff79f4788 in KWin::InputRedirection::init() () from /usr/lib64/libkwin.so.5 #12 0x00007ffff7a0e382 in KWin::Application::createInput() () from /usr/lib64/libkwin.so.5 #13 0x00000000004075d3 in ?? () #14 0x00007ffff7a0d01b in KWin::Application::start() () from /usr/lib64/libkwin.so.5 #15 0x000000000040ca26 in ?? () #16 0x00007fffef194670 in __libc_start_main () from /lib64/libc.so.6 #17 0x00000000004071a9 in _start () but, as said before, i don't know if this can be either useful or worthwile... If you like to see some other investigation, just let me know.
Created attachment 103823 [details] attachment-5783-0.html That looks like the first dbus call kwin does.
just checking: do you still experience this problem with an updated stack?
Just tried, and now export $(dbus-launch) ; kwin_wayland --xwayland Brings a black window where I can launch kwrite as described in kde wayland page. The messages are the following: No backend specified through command line argument, trying auto resolution OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 4.2 (Core Profile) Mesa 17.1.5 OpenGL shading language version string: 4.20 Driver: Intel GPU class: IvyBridge OpenGL version: 4.2 GLSL version: 4.20 Mesa version: 17.1.5 Linux kernel version: 4.12.3 Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running glamor: EGL version 1.4 (DRI2): X-Server started on display :1 Configuring Lock Action file:///usr/share/kwin/virtualkeyboard/main.qml:21:1: module "QtQuick.VirtualKeyboard" is not installed import QtQuick.VirtualKeyboard 2.1 ^ Closing the windows bring this error to the console: /usr/bin/Xwayland: symbol lookup error: /usr/lib/llvm/4/lib64/libLLVMAMDGPUCodeGen.so.4: undefined symbol: _ZN4llvm19MachinePassRegistry6RemoveEPNS_23MachinePassRegistryNodeE (maybe due to LTO compilation) So I guess the situation improved. sddm with plasma (Wayland) does not work, the window remains black. Weston starts up with no problem, so maybe the problem now is different. (I'm using LTO compiled kwin at this moment, with gcc) Qt 5.7.1 gcc 6.3.0 kdeframeworks 5.36.0 plasma 5.10.4
Good. I dare to mark as fixed. The bug concerning crash on tear down of KWin is already reported, investigated and understood and we have already patches floating around to fix it.