I've openSUSE 42.1 with Qt 5.7.0, KDE Plasma 5.7.4 and KDE Frameworks 5.25.0 running on a Lenovo P50 laptop. Whenever I connect a projector to the HDMI output my KDE session crashes. Following processes create coredumps: * /usr/lib64/libexec/drkonqi -platform xcb -display :0 --appname ksmserver --appp * /usr/bin/kactivitymanagerd start-daemon * /usr/lib64/libexec/kf5/klauncher --fd=8 * /usr/lib64/libexec/kf5/kscreen_backend_launcher But judging from the stack traces kscreen_backend_launcher crashes first, and then the rest follows. Stack trace for SIGSEGV in kscreen_backend_launcher: #0 XRandRScreen::toKScreenScreen (this=0x191eea0) at /usr/src/debug/libkscreen-5.7.4/backends/xrandr/xrandrscreen.cpp:67 #1 0x00007f50263a0cc1 in XRandRConfig::toKScreenConfig (this=0x191d660) at /usr/src/debug/libkscreen-5.7.4/backends/xrandr/xrandrconfig.cpp:117 #2 0x00007f502639d9e0 in XRandR::config (this=<optimized out>) at /usr/src/debug/libkscreen-5.7.4/backends/xrandr/xrandr.cpp:205 #3 0x0000000000404579 in BackendDBusWrapper::setConfig (this=0x1926f30, configMap=...) at /usr/src/debug/libkscreen-5.7.4/src/backendlauncher/backenddbuswrapper.cpp:87 #4 0x0000000000405854 in BackendAdaptor::setConfig (in0=..., this=<optimized out>) at /usr/src/debug/libkscreen-5.7.4/build/src/backendlauncher/backendadaptor.cpp:51 #5 BackendAdaptor::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=0x7ffc0a5ee700) at /usr/src/debug/libkscreen-5.7.4/build/src/backendlauncher/backendadaptor.moc:112 #6 0x0000000000405b43 in BackendAdaptor::qt_metacall (this=0x191e3e0, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7ffc0a5ee700) at /usr/src/debug/libkscreen-5.7.4/build/src/backendlauncher/backendadaptor.moc:155 #7 0x00007f5032ca1f9b in ?? () from /usr/lib64/libQt5DBus.so.5 #8 0x00007f5032ca6014 in ?? () from /usr/lib64/libQt5DBus.so.5 #9 0x00007f5032ca6870 in ?? () from /usr/lib64/libQt5DBus.so.5 #10 0x00007f5032ca8ebe in ?? () from /usr/lib64/libQt5DBus.so.5 #11 0x00007f5032153df6 in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5 #12 0x00007f503212a6bc in QCoreApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5 #13 0x00007f503212a5f5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5 #14 0x00007f503212c653 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5 #15 0x00007f5032179713 in ?? () from /usr/lib64/libQt5Core.so.5 #16 0x00007f502f208c84 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 #17 0x00007f502f208ed8 in ?? () from /usr/lib64/libglib-2.0.so.0 #18 0x00007f502f208f7c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0 #19 0x00007f5032178f7b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #20 0x00007f50321288cb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5 #21 0x00007f50321306c6 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5 #22 0x0000000000403542 in main (argc=1, argv=<optimized out>) at /usr/src/debug/libkscreen-5.7.4/src/backendlauncher/main.cpp:41 The line that crashes is 67: 66 XCB::ScopedPointer<xcb_randr_get_screen_resources_reply_t> screenResources(XRandR::screenResources()); 67 kscreenScreen->setMaxActiveOutputsCount(screenResources->num_crtcs); So it looks to me like XRandR::screenResources() returns an invalid/null pointer . I'd be happy to help further debugging this, but am not sure how to proceed. How do I attach e.g. a debugger early on during the login phase? Feel free to reach out to me also on IRC (kkoehne, e.g. on freenode/ #qt-labs) if I could be of any help. Reproducible: Always Steps to Reproduce: 1. Connect projector to HDMI input of laptop Actual Results: KDE session crashes. If one connects the projector in the KDM login screen, logging in fails.
Thanks for the bug report! I haven't seen this particular bit crashing, and of course it shouldn't. Would it be possible for you to try the KDE Neon git/unstable images and see if this improves the situation? We've fixed a number of problems in this part of the stack that may be at the root of the problem (especially, we're re-reading the crtcs at runtime now, which may fix this problem). If the problem persists, I'd like to have a look at the files in ~/.local/share/kscreen/* (that's configurations for different screens and the log of what exactly happened). Of course, an updated backtrace would be nice as well. https://community.kde.org/Solid/Projects/ScreenManagement#Debugging_Information has more information about obtaining useful debugging information,
Both KDE Neon "User Edition" (neon-useredition-20160912-1521-amd64.iso) and KDE Neon "Developer's Edition" (neon-devedition-gitunstable-20160914-0806-amd64.iso) do not expose the problem. However, they're also shipping a newer version of XRandR (1.5.0), compared to the version that's the default on OpenSUSE 42.1 (1.4.1). This in turn let me to update X11 by using the http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_42.1/ repository (also shipping XRandR 1.5.0) ... and voila, the problem is gone :) This hints towards that either either the data XRandR 1.4.1 returns is not properly handled by libkscreen, or that the real crash is actually inside XCB/xrandr. Is it worth the time to further investigate this?
To be honest, I'd rather spend my time on something else. The main reason is that we don't ship updates for older versions, so if we fixed something with respect to XRandR 1.4, this patch would still only go into Plasma 5.8. I think we can expect users who use an October release of Plasma to use the latest version of XRandR that has been released 6 months earlier. That said, thanks a lot for digging into the problem and the useful bug report!
The KDE side bug looks the same as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865001 (which I reported) and https://bugzilla.redhat.com/show_bug.cgi?id=1477592 and well, maybe https://bugzilla.redhat.com/show_bug.cgi?id=1406752 In my case the X server is dieing for other reasons ( a qxl bug) and I suspect that's the same problem with this case; but in either case KScreen shouldn't be segging. A bit of debug in XRandRScreen::toKScreenScreen and I see that: #0 XRandRScreen::toKScreenScreen (this=0x559dd8b68980) at ./backends/xrandr/xrandrscreen.cpp:68 screenResources = {d = 0x0} kscreenScreen = {value = 0x559dd8b78a70, d = 0x559dd8b78b90} #1 0x00007fe0e9b18aba in XRandRConfig::toKScreenConfig (this=<optimized out>) at ./backends/xrandr/xrandrconfig.cpp:117 config = {value = 0x559dd8b7ea80, d = 0x559dd8b7eb30} features = {i = 3} kscreenOutputs = {d = 0x559dd8b74bb0} which I guess is because X has died and the screens are well and truly gone. What's the right level to check for this and clean up?