I have a full backtrace for no XRandr:

Program received signal SIGSEGV, Segmentation fault.
0x00007fffee874a50 in xcb_setup_vendor_end () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
(gdb) bt                                                                                                                                                                                                                                   
#0  0x00007fffee874a50 in xcb_setup_vendor_end () from /usr/lib/x86_64-linux-gnu/libxcb.so.1                                                                                                                                               
#1  0x00007fffee874aa9 in xcb_setup_pixmap_formats_iterator () from /usr/lib/x86_64-linux-gnu/libxcb.so.1                                                                                                                                  
#2  0x00007fffee874ae9 in xcb_setup_roots_iterator () from /usr/lib/x86_64-linux-gnu/libxcb.so.1                                                                                                                                           
#3  0x00007fffeffbda4d in NETRootInfo::NETRootInfo (this=0x839620, connection=0x61c3c0, supportWindow=4294967295, wmName=0x7ffff78e696f "KWin", properties=..., windowTypes=..., states=..., properties2=..., actions=..., screen=0, 
    doActivate=true) at /home/martin/src/kf5/frameworks/kwindowsystem/src/netwm.cpp:669
#4  0x00007ffff775ae65 in KWin::RootInfo::RootInfo (this=0x839620, w=4294967295, name=0x7ffff78e696f "KWin", properties=..., types=..., states=..., properties2=..., actions=..., scr=0)
    at /home/martin/src/kf5/kde/workspace/kwin/netinfo.cpp:140
#5  0x00007ffff775ad4d in KWin::RootInfo::create () at /home/martin/src/kf5/kde/workspace/kwin/netinfo.cpp:125
#6  0x00007ffff7714ac4 in KWin::Workspace::init (this=0x7192a0) at /home/martin/src/kf5/kde/workspace/kwin/workspace.cpp:244
#7  0x00007ffff77144e7 in KWin::Workspace::Workspace (this=0x7192a0, restore=false) at /home/martin/src/kf5/kde/workspace/kwin/workspace.cpp:213
#8  0x00007ffff776af59 in KWin::Application::createWorkspace (this=0x7fffffffdcc0) at /home/martin/src/kf5/kde/workspace/kwin/main.cpp:375
#9  0x00007ffff7bd6aef in KWin::ApplicationX11::<lambda()>::operator()(void) const (__closure=0x7fffffffc890) at /home/martin/src/kf5/kde/workspace/kwin/main_x11.cpp:173
#10 0x00007ffff7bd796d in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, KWin::ApplicationX11::performStartup()::<lambda()> >::call(KWin::ApplicationX11::<lambda()>, void **) (f=..., arg=0x7fffffffca00)
    at /opt/qt5/include/QtCore/qobjectdefs_impl.h:494
#11 0x00007ffff7bd7922 in QtPrivate::Functor<KWin::ApplicationX11::performStartup()::<lambda()>, 0>::call<QtPrivate::List<>, void>(KWin::ApplicationX11::<lambda()> &, void *, void **) (f=..., arg=0x7fffffffca00)
    at /opt/qt5/include/QtCore/qobjectdefs_impl.h:551
#12 0x00007ffff7bd78bf in QtPrivate::QFunctorSlotObject<KWin::ApplicationX11::performStartup()::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=1, this_=0x678e30, 
    r=0x6694d0, a=0x7fffffffca00, ret=0x0) at /opt/qt5/include/QtCore/qobject_impl.h:192
#13 0x00007fffeedfc62b in QtPrivate::QSlotObjectBase::call (this=0x678e30, r=0x6694d0, a=0x7fffffffca00) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:124
#14 0x00007fffeedf970c in QMetaObject::activate (sender=0x6694d0, signalOffset=3, local_signal_index=1, argv=0x0) at kernel/qobject.cpp:3702
#15 0x00007fffeedf9024 in QMetaObject::activate (sender=0x6694d0, m=0x7ffff01ed720 <KSelectionOwner::staticMetaObject>, local_signal_index=1, argv=0x0) at kernel/qobject.cpp:3582
#16 0x00007fffeffd365b in KSelectionOwner::claimedOwnership (this=0x6694d0) at /opt/build/kf5/frameworks/kwindowsystem/src/moc_kselectionowner.cpp:150
#17 0x00007fffeffa82d9 in KSelectionOwner::Private::claimSucceeded (this=0x6841f0) at /home/martin/src/kf5/frameworks/kwindowsystem/src/kselectionowner.cpp:206
#18 0x00007fffeffa83fa in KSelectionOwner::Private::gotTimestamp (this=0x6841f0) at /home/martin/src/kf5/frameworks/kwindowsystem/src/kselectionowner.cpp:240
#19 0x00007fffeffa8a0c in KSelectionOwner::filterEvent (this=0x6694d0, ev_P=0x7fffd8001e80) at /home/martin/src/kf5/frameworks/kwindowsystem/src/kselectionowner.cpp:424
#20 0x00007fffeffa9271 in KSelectionOwner::Private::nativeEventFilter (this=0x6841f0, eventType=..., message=0x7fffd8001e80, result=0x7fffffffcd58) at /home/martin/src/kf5/frameworks/kwindowsystem/src/kselectionowner.cpp:117
#21 0x00007fffeedb1903 in QAbstractEventDispatcher::filterNativeEvent (this=0x639e80, eventType=..., message=0x7fffd8001e80, result=0x7fffffffcd58) at kernel/qabstracteventdispatcher.cpp:460
#22 0x00007fffe0ca46c9 in QXcbConnection::handleXcbEvent (this=0x61ae30, event=0x7fffd8001e80) at qxcbconnection.cpp:854
#23 0x00007fffe0ca6698 in QXcbConnection::processXcbEvents (this=0x61ae30) at qxcbconnection.cpp:1297
#24 0x00007fffe0ce71d6 in QXcbConnection::qt_static_metacall (_o=0x61ae30, _c=QMetaObject::InvokeMetaMethod, _id=1, _a=0x7fffd8002cb0) at .moc/moc_qxcbconnection.cpp:185
#25 0x00007fffeedf1d0f in QMetaCallEvent::placeMetaCall (this=0x7fffd8002cd0, object=0x61ae30) at kernel/qobject.cpp:485
#26 0x00007fffeedf2dd8 in QObject::event (this=0x61ae30, e=0x7fffd8002cd0) at kernel/qobject.cpp:1245
#27 0x00007fffe0ca7ab3 in QXcbConnection::event (this=0x61ae30, e=0x7fffd8002cd0) at qxcbconnection.cpp:1910
#28 0x00007fffef8fb5ec in QApplicationPrivate::notify_helper (this=0x612fb0, receiver=0x61ae30, e=0x7fffd8002cd0) at kernel/qapplication.cpp:3720
#29 0x00007fffef8f8d68 in QApplication::notify (this=0x7fffffffdcc0, receiver=0x61ae30, e=0x7fffd8002cd0) at kernel/qapplication.cpp:3164
#30 0x00007ffff7769ddf in KWin::Application::notify (this=0x7fffffffdcc0, o=0x61ae30, e=0x7fffd8002cd0) at /home/martin/src/kf5/kde/workspace/kwin/main.cpp:241
#31 0x00007fffeedb63bc in QCoreApplication::notifyInternal (this=0x7fffffffdcc0, receiver=0x61ae30, event=0x7fffd8002cd0) at kernel/qcoreapplication.cpp:935
#32 0x00007fffeedba01d in QCoreApplication::sendEvent (receiver=0x61ae30, event=0x7fffd8002cd0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:228
#33 0x00007fffeedb76f5 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x6032b0) at kernel/qcoreapplication.cpp:1552
#34 0x00007fffeee2baff in QEventDispatcherUNIX::processEvents (this=0x639e80, flags=...) at kernel/qeventdispatcher_unix.cpp:579
#35 0x00007fffe0d2a30e in QUnixEventDispatcherQPA::processEvents (this=0x639e80, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:62
#36 0x00007fffeedb3060 in QEventLoop::processEvents (this=0x7fffffffdbe0, flags=...) at kernel/qeventloop.cpp:128
#37 0x00007fffeedb3339 in QEventLoop::exec (this=0x7fffffffdbe0, flags=...) at kernel/qeventloop.cpp:204

The xcb part:
#0  xcb_setup_vendor_end (R=R@entry=0x0) at xproto.c:1569
#1  0x00007fffee874aa9 in xcb_setup_pixmap_formats_iterator (R=R@entry=0x0) at xproto.c:1622
#2  0x00007fffee874ae9 in xcb_setup_roots_iterator (R=0x0) at xproto.c:1659
#3  0x00007fffeffbda4d in NETRootInfo::NETRootInfo (this=0x838ce0, connection=0x61c3c0, supportWindow=4294967295, wmName=0x7ffff78e696f "KWin", properties=..., windowTypes=..., states=..., properties2=..., actions=..., screen=0, 
    doActivate=true) at /home/martin/src/kf5/frameworks/kwindowsystem/src/netwm.cpp:669

Relevant code section:
const xcb_setup_t *setup = xcb_get_setup(p->conn);
xcb_screen_iterator_t it = xcb_setup_roots_iterator(setup);

Added some debug information:

qDebug() << "!!!!! Connection has error: " << xcb_connection_has_error(connection());
qDebug() << "!!!! setup: " << xcb_get_setup(connection());

gives us:

kwin(20197)/(default) KWin::RootInfo::create: !!!!! Connection has error:  2
kwin(20197)/(default) KWin::RootInfo::create: !!!! setup:  0x0

while checking Qt code I noticed that Qt 5.5 has a patch for fixing no xrandr situation. Relevant upstream bug report is: https://bugreports.qt.io/browse/QTBUG-31389

While I haven't tested with Qt 5.5 yet, I assume this change will fix the crash. Because of that I set to RESOLVED UPSTREAM. If you are still unable to use kwin without xrandr once you have Qt 5.5 please reopen.

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

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

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

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

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

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

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

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

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

QT 5.5.0 is now released: https://wiki.qt.io/Qt-5.5-release

(In reply to Martin Gräßlin from comment #4)
> while checking Qt code I noticed that Qt 5.5 has a patch for fixing no
> xrandr situation. Relevant upstream bug report is:
> https://bugreports.qt.io/browse/QTBUG-31389
> 
> While I haven't tested with Qt 5.5 yet, I assume this change will fix the
> crash. Because of that I set to RESOLVED UPSTREAM. If you are still unable
> to use kwin without xrandr once you have Qt 5.5 please reopen.

Martin,
   Now that Qt 5.5 is out does kwin need to be re-compiled with it? I am really missing my extra monitors.

Thanks

> Now that Qt 5.5 is out does kwin need to be re-compiled with it?

no, there is no need to recompile KWin.

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

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

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

I upgraded to Qt 5.5 via the Repo copr.fedoraproject.org/coprs/dvratil/qt5/repo/fedora-22/dvratil-qt5-fedora-22.repo as stated as the resolution.

Right after Enabling Xinerama to activate the three monitors this crash happens after logging on.  The log on screen comes up will all the monitors active but the desktop will not come up.

We are sorry, kded5 closed unexpectedly
You cannot report this error, because kded5 does not provide a bug reporting address.
The crash report is below (kded5-20150807-163406.kcrash.txt):
Application: kded5 (kded5), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fd3d5965780 (LWP 2500))]

Thread 3 (Thread 0x7fd3bea78700 (LWP 2503)):
#0  0x00007fd3d25542fd in poll () from /lib64/libc.so.6
#1  0x00007fd3cd61e182 in _xcb_conn_wait () from /lib64/libxcb.so.1
#2  0x00007fd3cd61fc77 in xcb_wait_for_event () from /lib64/libxcb.so.1
#3  0x00007fd3c35cb599 in QXcbEventReader::run() () from /lib64/libQt5XcbQpa.so.5
#4  0x00007fd3d316054e in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5
#5  0x00007fd3d14ef754 in ?? () from /usr/lib64/nvidia-304xx/libGL.so.1
#6  0x00007fd3d2248555 in start_thread () from /lib64/libpthread.so.0
#7  0x00007fd3d255fb9d in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7fd3abdad700 (LWP 2513)):
#0  0x00007fd3d25542fd in poll () from /lib64/libc.so.6
#1  0x00007fd3d1cfedbc in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#2  0x00007fd3d1cff142 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#3  0x00007fd3ac6c4696 in gdbus_shared_thread_func () from /lib64/libgio-2.0.so.0
#4  0x00007fd3d1d260a5 in g_thread_proxy () from /lib64/libglib-2.0.so.0
#5  0x00007fd3d14ef754 in ?? () from /usr/lib64/nvidia-304xx/libGL.so.1
#6  0x00007fd3d2248555 in start_thread () from /lib64/libpthread.so.0
#7  0x00007fd3d255fb9d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fd3d5965780 (LWP 2500)):
[KCrash Handler]
#5  0x00007fd3cd622920 in xcb_setup_vendor_end () from /lib64/libxcb.so.1
#6  0x00007fd3cd622979 in xcb_setup_pixmap_formats_iterator () from /lib64/libxcb.so.1
#7  0x00007fd3cd6229b9 in xcb_setup_roots_iterator () from /lib64/libxcb.so.1
#8  0x00007fd3d05078c8 in NETRootInfo::NETRootInfo(xcb_connection_t*, QFlags<NET::Property>, QFlags<NET::Property2>, int, bool) () from /lib64/libKF5WindowSystem.so.5
#9  0x00007fd3d04f05bb in NETEventFilter::NETEventFilter(KWindowSystemPrivateX11::FilterInfo) () from /lib64/libKF5WindowSystem.so.5
#10 0x00007fd3d04f13a1 in KWindowSystemPrivateX11::init(KWindowSystemPrivateX11::FilterInfo) () from /lib64/libKF5WindowSystem.so.5
#11 0x00007fd3d04f1516 in KWindowSystemPrivateX11::connectNotify(QMetaMethod const&) () from /lib64/libKF5WindowSystem.so.5
#12 0x00007fd3d04ea1e0 in KWindowSystem::connectNotify(QMetaMethod const&) () from /lib64/libKF5WindowSystem.so.5
#13 0x00007fd3d337294a in QMetaObjectPrivate::connect(QObject const*, int, QMetaObject const*, QObject const*, int, QMetaObject const*, int, int*) () from /lib64/libQt5Core.so.5
#14 0x00007fd3d3376a5b in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) () from /lib64/libQt5Core.so.5
#15 0x00007fd37b52f3ea in KHotKeys::WindowsHandler::WindowsHandler(bool, QObject*) () from /lib64/libkhotkeysprivate.so.5
#16 0x00007fd37b5252db in KHotKeys::init_global_data(bool, QObject*) () from /lib64/libkhotkeysprivate.so.5
#17 0x00007fd37b743849 in KHotKeysModule::initialize() () from /usr/lib64/qt5/plugins/kded_khotkeys.so
#18 0x00007fd37b744bd5 in KHotKeysModule::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib64/qt5/plugins/kded_khotkeys.so
#19 0x00007fd3d3371021 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5
#20 0x00007fd3d4e3043c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5
#21 0x00007fd3d4e35906 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5
#22 0x00007fd3d334161b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib64/libQt5Core.so.5
#23 0x00007fd3d3343a16 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5
#24 0x00007fd3d3397983 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5
#25 0x00007fd3d1cfea8a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#26 0x00007fd3d1cfee20 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#27 0x00007fd3d1cfeecc in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#28 0x00007fd3d3397d8f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#29 0x00007fd3d333edaa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#30 0x00007fd378ae53bb in KAuth::Polkit1Backend::actionExists(QString const&) () from /usr/lib64/qt5/plugins/kauth/backend/kauth_backend_plugin.so
#31 0x00007fd3b722055e in KAuth::Action::setName(QString const&) () from /lib64/libKF5Auth.so.5
#32 0x00007fd3b72205c9 in KAuth::Action::Action(QString const&) () from /lib64/libKF5Auth.so.5
#33 0x00007fd3a371707d in PowerDevilUPowerBackend::init() () from /usr/lib64/qt5/plugins/kded_powerdevil.so
#34 0x00007fd3a34ca927 in PowerDevil::Core::loadCore(PowerDevil::BackendInterface*) () from /lib64/libpowerdevilcore.so.2
#35 0x00007fd3a370a71f in KDEDPowerDevil::init() () from /usr/lib64/qt5/plugins/kded_powerdevil.so
#36 0x00007fd3d3371021 in QObject::event(QEvent*) () from /lib64/libQt5Core.so.5
#37 0x00007fd3d4e3043c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5
#38 0x00007fd3d4e35906 in QApplication::notify(QObject*, QEvent*) () from /lib64/libQt5Widgets.so.5
#39 0x00007fd3d334161b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib64/libQt5Core.so.5
#40 0x00007fd3d3343a16 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib64/libQt5Core.so.5
#41 0x00007fd3d3397983 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib64/libQt5Core.so.5
#42 0x00007fd3d1cfea8a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#43 0x00007fd3d1cfee20 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#44 0x00007fd3d1cfeecc in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#45 0x00007fd3d3397d8f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#46 0x00007fd3d333edaa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib64/libQt5Core.so.5
#47 0x00007fd3d3346e6c in QCoreApplication::exec() () from /lib64/libQt5Core.so.5
#48 0x00007fd3d556fa04 in kdemain () from /lib64/libkdeinit5_kded5.so
#49 0x00007fd3d247d700 in __libc_start_main () from /lib64/libc.so.6
#50 0x0000000000400829 in _start ()

That backtrace is from kded.
=> Does kwin crash as well? (ie. "does the crash dialog have a titlebar?")

error 2 is XCB_CONN_CLOSED_EXT_NOTSUPPORTED, since we know that randr isn't available, "something™" will make an uncovered randr call (and break the connection)

"grep randr" in kwindowsystem exposes no call, but if kded crashes and (at least?) plasmashell fails as well, the malicous call will be in some common library - either Qt or maybe kscreen.

I will ssh into the system before it logs on and run "grep randr" before it gets frozen or crashing.  Is there something else that I could run that would gather some of the logs you need to troubleshoot this issue?

grepping only helps on the source code and it reveals that kwindowsystem (what triggers the crash, but is just pointing out that "this client has lost the connection to the X111 server") does not make randr calls.

KWin makes some, but afaics they're either covered or user triggered (inverting the screen colors actually tries to adjust gamma ramps via randr first - we should fix that but it's apparently not the trigger here)

Since the last crashign client was kded, it seems the randr calls are made by something™ else and something™ will likely be either kscreen (if only kded crashes) or  Qt (if everything crashes)

=> what you can do is to ssh in, (don't forget to "export DISPLAY=:0") and check whether
a) kwin is running
b) you can start a plain and ideally simple Qt5 application
c) you can start something like "kwrite" (a KDE application)

I am having this issue as well. KWin (kwin_x11) segfaults on /lib64/libthread_db.so.1 and the backtrace looks to be the same, crashing in libQt5Core.so.5

The backtrace is near identical to the first poster in this thread.

I recently upgraded to FC 22 from FC 21 and am using the same previously-working xorg.conf file with the same quad-monitor setup.

If I switch to two monitors, everything works OK.

The problem is not the amount of screens but the (implicitly required by the nvidia driver) absence of the RandR extension, which however Qt5 hard-depends on.

It's said to be fixed in Qt 5.5, while I'm personally not convinced that the linked Qt patch can cover up this generally.

Current question is *what* makes the uncovered call into randr (KWindowSystem is only the messenger here - it crashed because it doesn't check for an xcb error in some places; it would then have to abort anyway, though)

=> see (end of) comment #23

I have installed dvratil's COPR repostiory to get new qt packages (his repo currrently provides version 5.5.0), and it does not fix the issue.

Can we get this issue marked as NOT resolved? Martin marked it as resolved without even having tested it, and it's clear that it's not fixed.

It's resolved "upstream" what's our bugzillas polite but rather ambigious way to say: "someone elses problem"

Since it's pretty much sure that neither KWindowSystem nor KWin make the (causing, as mentioned there's one uncoditional call in KWin to invert the screen colors, but you must press a shortcut to trigger this; also we've a kded crash reported) uncoditional RandR call, the most important thing is to figure *what* makes this call, so we can address it there.

See comment #23 for a basic filter test.

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

I'd be happy to participate in debugging this further. Unfortunately I don't know how to do all the debug actions requested.

Comment #23 states:

"=> what you can do is to ssh in, (don't forget to "export DISPLAY=:0") and check whether
a) kwin is running
b) you can start a plain and ideally simple Qt5 application
c) you can start something like "kwrite" (a KDE application)"

Can you give me a bit more detail on how I might perform this debugging? For example, I can't start a Qt5 application because I can't even get to the desktop. Am I missing what you want me to do?

KWin is reporting it's crashed during sign-in (it never starts fully)

I can't get to the desktop.

The magic phrase is "ssh in" - it will be required to access the system via either network or from VTn (textshells you reach by pressing Ctrl+Alt+F1, Ctrl+Alt+F2, Ctrl+Alt+F3, ...)

you'll there have to enter
   export DISPLAY=:0
to hint that you want to talk to the running X11 server.

If you can *actually* not log in, the ksmserver process would crash for the same reason (and you be back on the login screen)

In this case you'd rather start a failsafe session  (naked X11 server and an xterm) and try to run things (eg. enter "kwrite") from the xterm.

I started hitting this same bug today when I added another Nvidia card into my computer to start using some six monitor goodness.  Instead I got some fun crashing.

To try to move this bug forward I did  the ssh fun with kate as Thomas requested above.  Here is the trace:
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/kate...(no debugging symbols found)...done.
[New LWP 2965]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `kate'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f4594f5d5f8 in raise () from /usr/lib/libc.so.6
(gdb) thread apply all bt 100

Thread 1 (Thread 0x7f45956a8840 (LWP 2965)):
#0  0x00007f4594f5d5f8 in raise () from /usr/lib/libc.so.6
#1  0x00007f4594f5ea7a in abort () from /usr/lib/libc.so.6
#2  0x00007f45903aef31 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#3  0x00007f457ef4396e in QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) () from /usr/lib/libQt5XcbQpa.so.5
#4  0x00007f457ef4904d in QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) () from /usr/lib/libQt5XcbQpa.so.5
#5  0x00007f457f1f023d in ?? () from /usr/lib/qt/plugins/platforms/libqxcb.so
#6  0x00007f459120e582 in QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) () from /usr/lib/libQt5Gui.so.5
#7  0x00007f459121a7c2 in QGuiApplicationPrivate::createPlatformIntegration() () from /usr/lib/libQt5Gui.so.5
#8  0x00007f459121b6dd in QGuiApplicationPrivate::createEventDispatcher() () from /usr/lib/libQt5Gui.so.5
#9  0x00007f45905a5df6 in QCoreApplication::init() () from /usr/lib/libQt5Core.so.5
#10 0x00007f45905a5e66 in QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) () from /usr/lib/libQt5Core.so.5
#11 0x00007f459121d439 in QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) () from /usr/lib/libQt5Gui.so.5
#12 0x00007f45919fdb7d in QApplication::QApplication(int&, char**, int) () from /usr/lib/libQt5Widgets.so.5
#13 0x00007f459535479b in kdemain () from /usr/lib/libkdeinit5_kate.so
#14 0x00007f4594f4a610 in __libc_start_main () from /usr/lib/libc.so.6
#15 0x0000000000400779 in _start ()

This is an up-to-date Arch box.  I can rebuild any packages developers want with debug symbols as needed.  I can probably also test patches.  All my qt packages are at 5.5.0-2.

Thanks!

This is a crash in the QXcbConnection constructor and -lilkely- means you forgot to

   export DISPLAY=:0

;-)

Next, we don't need the crash, but the malicious randr calls.
So in gdb you need to set breakpoints

   rbreak xcb_xrandr_.*
   rbreak XRR.*

the second is for Xlib calls (though i think it uses xcb internally anyway, so the second patter might just add false positive matches)

Then you need to
   continue

and wait for the break to be hit.
Then call
   bt

to see the stack at this position.

I verified I did have DISPLAY exported as :0.  Unfortunately, what I hadn't considered is since my user hasn't logged in yet the Xauthority stuff isn't set up yet.  I should have noticed that my kate actually died from:
Invalid MIT-MAGIC-COOKIE-1 keyQXcbConnection: Could not connect to display :0

I found my cookie from the Xorg server (-auth flag) and copied it to my user directory and xauth merged it.  Now I can run commands.  Unfortunately I don't appear to be hitting those breakpoints:
Reading symbols from kate...(no debugging symbols found)...done.
(gdb) rbreak xcb_xrandr_.*
(gdb) rbreak XRR.*
(gdb) run
Starting program: /usr/bin/kate 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffdf429700 (LWP 2097)]
QDBusConnection: name 'org.kde.kglobalaccel' had owner '' but we thought it was ':1.1'
detected kglobalaccel restarting, re-registering all shortcut keys

[Let it run for ~40 seconds.  CTRL-C'd it]

^C
Program received signal SIGINT, Interrupt.
0x00007ffff785a18d in poll () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff785a18d in poll () from /usr/lib/libc.so.6
#1  0x00007fffee530c7c in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fffee530d8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007ffff2e4825b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#4  0x00007ffff2def26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#5  0x00007ffff2df720c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#6  0x00007ffff7ba8d54 in kdemain () from /usr/lib/libkdeinit5_kate.so
#7  0x00007ffff779a610 in __libc_start_main () from /usr/lib/libc.so.6
#8  0x0000000000400779 in _start ()

Not sure why I am not hitting the breakpoints you gave me.  Perhaps I lack the symbols for gdb to find to break on?  Will look into it more tomorrow.  Thanks for the pointers!

d'ohhh - it's because xcb is dlopen'd with the QPA plugin.
One could "set breakpoint pending on", but that doesn't work w/ rbreak (and you don't want to enter all xcb_randr calls by hand...)

That's inconvenient.

You'll have to

break QFactoryLoader::instance
(you'll get a warning and a question to break deferred, enter "y")
run
(stops at QFactoryLoader::instance)
del 1
(remove QFactoryLoader::instance breakpoint)
break dlopen
(catch next dlopen)
continue
(stops at dlopen)
finish
(jump behind dlopen, xcb is now loaded)
del 2
(get rid of dlopen break)
rbreak xcb_randr_.*
(should print a list of symbols, enter "q" to skip printing the list - it's long ;-)
continue
(should stop at malicious randr call)
bt
(finally see what makes it)

Thanks for your awesome directions.  No problems in hitting it now:
Breakpoint 13, 0x00007fffe1788d10 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*)@plt ()
   from /usr/lib/libQt5XcbQpa.so.5
(gdb) bt
#0  0x00007fffe1788d10 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*)@plt () from /usr/lib/libQt5XcbQpa.so.5
#1  0x00007fffe179221d in QXcbConnection::initializeScreens() () from /usr/lib/libQt5XcbQpa.so.5
#2  0x00007fffe1793514 in QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) () from /usr/lib/libQt5XcbQpa.so.5
#3  0x00007fffe179904d in QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) () from /usr/lib/libQt5XcbQpa.so.5
#4  0x00007fffe1a4023d in ?? () from /usr/lib/qt/plugins/platforms/libqxcb.so
#5  0x00007ffff3a5e582 in QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) () from /usr/lib/libQt5Gui.so.5
#6  0x00007ffff3a6a7c2 in QGuiApplicationPrivate::createPlatformIntegration() () from /usr/lib/libQt5Gui.so.5
#7  0x00007ffff3a6b6dd in QGuiApplicationPrivate::createEventDispatcher() () from /usr/lib/libQt5Gui.so.5
#8  0x00007ffff2df5df6 in QCoreApplication::init() () from /usr/lib/libQt5Core.so.5
#9  0x00007ffff2df5e66 in QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) () from /usr/lib/libQt5Core.so.5
#10 0x00007ffff3a6d439 in QGuiApplication::QGuiApplication(QGuiApplicationPrivate&) () from /usr/lib/libQt5Gui.so.5
#11 0x00007ffff424db7d in QApplication::QApplication(int&, char**, int) () from /usr/lib/libQt5Widgets.so.5
#12 0x00007ffff7ba479b in kdemain () from /usr/lib/libkdeinit5_kate.so
#13 0x00007ffff779a610 in __libc_start_main () from /usr/lib/libc.so.6
#14 0x0000000000400779 in _start ()
(gdb)

No, sorry :-(
That one hits for the "xcb_randr_get_output_info_reply_t" parameter - it should however be a nullptr and the actual xrandr call in the function be skipped.

Just continue (on and on) - the killer will look like eg.
Breakpoint 3, 0xb1fefd70 in xcb_randr_get_output_primary_reply@plt () from /usr/lib/libQt5XcbQpa.so.5

ie. break on an actual xcb_randr function call (I maybe should have mentioned that ...)

Hmmm.  Here is what continue brings:
(gdb) continue
Continuing.
[New Thread 0x7fffdf429700 (LWP 1270)]

Breakpoint 13, 0x00007fffe1788d10 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*)@plt ()
   from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.

Breakpoint 30, 0x00007fffe178f940 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*) ()
   from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.

Breakpoint 12, 0x00007fffe1787f70 in QXcbScreen::QXcbScreen(QXcbConnection*, QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*, QString)@plt () from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.
QDBusConnection: name 'org.kde.kglobalaccel' had owner '' but we thought it was ':1.1'
detected kglobalaccel restarting, re-registering all shortcut keys

At this point nothing comes back forever (let it run for 10 minutes).  Full session output is available at:
http://pastebin.com/UF19YXKy so you can make sure my clipping isn't causing issues.  

Is kate a good test or should I use something other executable?

I was just laying in bed thinking about this problem and wondered to myself why I was trying it on kate and not kwin_x11 since I know kwin_x11 exhibits this issue. 

I followed your above steps for kwin_x11.  Here is the bt:
(gdb) bt
#0  0x00007ffff71d0660 in xcb_randr_get_screen_resources_unchecked@plt () from /usr/lib/libkwin.so.5
#1  0x00007ffff723ae74 in ?? () from /usr/lib/libkwin.so.5
#2  0x00007ffff7236941 in ?? () from /usr/lib/libkwin.so.5
#3  0x00007ffff7235afa in KWin::Screens::create(QObject*) () from /usr/lib/libkwin.so.5
#4  0x00007ffff7223149 in KWin::Application::createScreens() () from /usr/lib/libkwin.so.5
#5  0x00007ffff71de5f6 in KWin::Workspace::init() () from /usr/lib/libkwin.so.5
#6  0x00007ffff71e04ab in KWin::Workspace::Workspace(QString const&) () from /usr/lib/libkwin.so.5
#7  0x00007ffff72230f0 in KWin::Application::createWorkspace() () from /usr/lib/libkwin.so.5
#8  0x00007ffff7bd6edc in ?? () from /usr/lib/libkdeinit5_kwin_x11.so
#9  0x00007ffff569be77 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5
#10 0x00007ffff6d0b42b in KSelectionOwner::Private::claimSucceeded() () from /usr/lib/libKF5WindowSystem.so.5
#11 0x00007ffff6d0bc71 in KSelectionOwner::filterEvent(void*) () from /usr/lib/libKF5WindowSystem.so.5
#12 0x00007ffff566a3ff in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long*) () from /usr/lib/libQt5Core.so.5
#13 0x00007fffdd705554 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () from /usr/lib/libQt5XcbQpa.so.5
#14 0x00007fffdd706303 in QXcbConnection::processXcbEvents() () from /usr/lib/libQt5XcbQpa.so.5
#15 0x00007ffff569ceb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#16 0x00007ffff63a700c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#17 0x00007ffff63ac4e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#18 0x00007ffff566d89b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#19 0x00007ffff566fc96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#20 0x00007ffff56c17c2 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#21 0x00007fffdd76835d in ?? () from /usr/lib/libQt5XcbQpa.so.5
#22 0x00007ffff566b26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#23 0x00007ffff567320c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#24 0x00007ffff7bd873b in kdemain () from /usr/lib/libkdeinit5_kwin_x11.so
#25 0x00007ffff7632610 in __libc_start_main () from /usr/lib/libc.so.6
#26 0x00000000004007c9 in _start ()

At least I can hit one of the randr calls.  Not sure why #1 and #2 aren't rendering in the symbols.

private symbols being stripped from your binary, doesn't matter.

Many thanks for testing.
a) this is a bug in KWin
b) obviously grepping code terribly fails on code generators ;-)

can you also try a patch? (I didn't test it at all - need to check it later this day otherwise)

diff --git a/screens_xrandr.cpp b/screens_xrandr.cpp
index bd73e6b..4063846 100644
--- a/screens_xrandr.cpp
+++ b/screens_xrandr.cpp
@@ -42,6 +42,10 @@ void XRandRScreens::update()
     };
     m_geometries.clear();
     m_names.clear();
+    if (!Xcb::Extensions::self()->isRandrAvailable()) {
+        fallback();
+        return;
+    }
     T resources(rootWindow());
     if (resources.isNull()) {
         fallback();

Turns out it was a bug in kwin :). Also turns out your polite but ambiguous way for saying "somebody else's problem" was used here way too fast. As I pointed out, nobody tested the supposed Qt patch, nobody got to the root of the problem, instead "not our problem" was used and the report was closed.

Leaving aside that Martin's assumption the covered unprotected randr call in Qt would have been the (only) trigger was rather pre-emptive, but not unreasonable (notably since there've been crashes in other clients as well)

Leaving aside that he explicitly asked to re-open the bug in case it's still reproducible with Qt5.5 (because 5.4 had apparently triggered the problem anyway) - what *you* as the bug reporter could have done anytime. (Ok: hopefully, @Martin, do we have the state set by maintainers locked - even against the reporter?)

And leaving aside that that in comment #25 I already explicitly stated that I doubt the Qt patch could provide a global solution to the problem.

And leaving aside that at least personally I give a complete shit about the resolution tag of bug reports - the validity of a bug is determined by incoming reports, not by some sissy byte in a bugtracker.

Leaving all that aside:
Did you somehow miss that, though completely without your assistance, but four weeks after it was clear that Qt5.5 would not resolve it completely and only 25 hours after an affected user stood up to launch gdb for inspection, we actually *did* get to the root of the problem?

But since you seem to care so much about the tags, I'll just fix the remaining ones as well.

Bug got closed without 

* even bothering trying to repro it
* without testing a proper patch
* without finding the root of the bug

This sounds to me pretty much as "hey, I completely and absolutely don't give a fucking fuck about your bug report. My magic ball told me it *might* be some Qt issue (because Qt caused some other crashes that might look like this one) which *hopefully* will be fixed in some future version, so I'm closing this as 'not my problem'. Oh, well, I'm not even sure it's Qt or something else, but ¯\_(ツ)_/¯ deal with it :)".

(and btw, this same attitude, very proper of Martin, has happened to pretty much half of all the kwin/plasma bugs I have filled).

I figured out I'd just switch to KDE 4.x. That is why I didn't send any more info nor kept caring about the issue.

Of course I don't know Martins intentions, but what I read in comment #4 is:
"I know Qt5 has a bug prone to cause this abort. It will be fixed in 5.5 and I believe this resolves this bug as well. Please re-open otherwise."

And in case it's not clear:
this *is* a cornercase and one has to damage ones X11 setup in order to reproduce it - nothing I would personally do for no strong reason either.

His assumption turned out wrong, yes. So what?
Seriously, why didn't you just reset the bug state as explicitly asked for - instead of moaning around without *any* effect?

Thomas: I tried your patch.  The good news is the loader bar shoots over farther faster.  I also received no coredumps from kwin.

The bad news is I received a coredump from kactivitymanagerd and two from kded5.  I am working on collecting those backtraces.  Want me to add them here or open new bugs for each?

coredumpctl output:
Sun 2015-09-06 07:59:32 PDT    1305  1000  1000  11 * /usr/bin/kactivitymanagerd
Sun 2015-09-06 07:59:33 PDT    1321  1000  1000  11 * /usr/bin/kdeinit5
Sun 2015-09-06 07:59:33 PDT   23088  1000  1000   6 * /usr/bin/kdeinit5
Sun 2015-09-06 08:00:47 PDT   23221  1000  1000  11 * /usr/bin/kactivitymanagerd
Sun 2015-09-06 08:00:48 PDT   23258  1000  1000  11 * /usr/bin/kded5
Sun 2015-09-06 08:00:49 PDT   23312  1000  1000  11 * /usr/bin/kded5

Thanks for all your help.

I could successfully start kded5 with loaded kscreen2 module (randomly blaming that) but didn't think of kactivitymanagerd at all.

Either just record the backtraces here (I'll dispatch them) or file new bugs against kactivitymanager and whatever kded module is responsible.

Another issue I ran into was that compositing didn't work at all, but I also just naively disabled the randr extension.
=> Do you have usable compositing in KWin?

I have been playing with this for the last hour or so and I can not actually get to the desktop.  In my previous post I said I was getting coredumps from kactivitymanagerd and kded5.  That doesn't seem to be happening after a power cycle.  No clue why.  Magic? :-)

My current state of the union is the box boots up to sddm and I can type my login information.  At that time I see this:
http://imgur.com/EKHoJBh

This remains forever I assume (I have had it ~15 minutes).  There are no new core files generated though.  I have repeated this 3 times.  The box is still responsive over SSH.  dmesg doesn't show anything negative and the process list looks relatively fine (kwin_x11, klauncher, kded5, ksmserver, krunner, plasmashell, kglobalaccel5, kactivitymanagerd, kaccess) are all present.  kactivitymanagerd has start-daemon after it so I don't know if that indicates anything.

Standing by with gdb and a hex editor.  Let me know if there is anything useful I can do t.

I pretty much see the same error, the main difference is that I can start applications with Alt-F2.
Also applications I had in the kde4 autostart (pidgin) start and work as expected
kwin seems to work. I can use all started applications, resize, move, and switch between them (even with Alt-Tab).
But the Desktop background is never redrawn and shows the old window content.
The first time I login I see kactivitymanager crashing in libQt5Sql, afterwards everything seems right.
The only relevant message in .xsession-errors seems to be:
  kscreen: Launcher finished with exit code 2 , status 0
  kscreen: Launcher failed to load any backend: KScreen will be useless
  Error found while setting up ShellCorona's KScreen:  "Failed to prepare backend"

I verified I can NOT do the Alt-F2 stuff or do anything that actually gives me a program.  Manually setting DISPLAY over ssh and opening a program (kate) doesn't show anything on the screens either.

My .xsession-errors closely follows Bernd's output:
startkde: Starting up...
kbuildsycoca5 running...
Service started, version: 6.2.0
Failure: Timeout
kscreen: Launcher finished with exit code 2 , status 0
kscreen: Launcher failed to load any backend: KScreen will be useless
Error found while setting up ShellCorona's KScreen:  "Failed to prepare backend"

What Bernd sees is likely a problem in plasmashell which asks kscreen for a size to take, but kscreen, lacking any backend, doesn't know a size and will likely (just as kwin, btw) default to "0x0" (both should likely just use the size of the root window)

This *might* be coverable with a KWin rule that enforces a fixed geometry for desktop type windows (kcmshell5 kwinrules)

Barry, given the massive trouble I had with compositing w/o randr extension: does it "help" to suspend the compositor?(SHIFT+Alt+F12)

xwininfo shows that both have the size 0x0, if I force a different size the size doesn't change according to xwininfo.
The only difference I notice is that the KRunner is placed in the middle of the screen and not on the left.
And I get an additional crash in kded5 (which in any case completely utilizes one core):

#5  xcb_setup_vendor_end (R=R@entry=0x0) at xproto.c:869
#6  0x00007fdfa5398119 in xcb_setup_pixmap_formats_iterator (R=R@entry=0x0) at xproto.c:892
#7  0x00007fdfa5398159 in xcb_setup_roots_iterator (R=0x0) at xproto.c:909
#8  0x00007fdfa7906808 in NETRootInfo::NETRootInfo(xcb_connection_t*, QFlags<NET::Property>, QFlags<NET::Property2>, int, bool) () from /usr/lib/libKF5WindowSystem.so.5
#9  0x00007fdf7c2ff08b in ?? () from /usr/lib/qt/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so
#10 0x00007fdf7c2ffe71 in ?? () from /usr/lib/qt/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so
#11 0x00007fdf7c2fffe6 in ?? () from /usr/lib/qt/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so
#12 0x00007fdfa78f2cf8 in KWindowSystem::connectNotify(QMetaMethod const&) () from /usr/lib/libKF5WindowSystem.so.5
#13 0x00007fdfa935eb6a in ?? () from /usr/lib/libQt5Core.so.5
#14 0x00007fdfa9362dcb in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) () from /usr/lib/libQt5Core.so.5
#15 0x00007fdf769c0aba in KHotKeys::WindowsHandler::WindowsHandler(bool, QObject*) () from /usr/lib/libkhotkeysprivate.so.5
#16 0x00007fdf769b6b9b in KHotKeys::init_global_data(bool, QObject*) () from /usr/lib/libkhotkeysprivate.so.5
#17 0x00007fdf76bd35e9 in ?? () from /usr/lib/qt/plugins/kded_khotkeys.so
#18 0x00007fdf76bd4815 in ?? () from /usr/lib/qt/plugins/kded_khotkeys.so
#19 0x00007fdfa935ceb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#20 0x00007fdfaae7100c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#21 0x00007fdfaae764e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#22 0x00007fdfa932d89b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#23 0x00007fdfa932fc96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#24 0x00007fdfa9383e33 in ?? () from /usr/lib/libQt5Core.so.5
#25 0x00007fdfa85dd9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#26 0x00007fdfa85ddce0 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x00007fdfa85ddd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#28 0x00007fdfa938423f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#29 0x00007fdfa932b26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#30 0x00007fdf74d6838b in ?? () from /usr/lib/qt/plugins/kauth/backend/kauth_backend_plugin.so
#31 0x00007fdf9270174e in KAuth::Action::setName(QString const&) () from /usr/lib/libKF5Auth.so.5
#32 0x00007fdf927017b9 in KAuth::Action::Action(QString const&) () from /usr/lib/libKF5Auth.so.5
#33 0x00007fdf8105e634 in PowerDevilUPowerBackend::init() () from /usr/lib/qt/plugins/kded_powerdevil.so
#34 0x00007fdf80e15747 in PowerDevil::Core::loadCore(PowerDevil::BackendInterface*) () from /usr/lib/libpowerdevilcore.so.2
#35 0x00007fdf8105394f in ?? () from /usr/lib/qt/plugins/kded_powerdevil.so
#36 0x00007fdfa935ceb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#37 0x00007fdfaae7100c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#38 0x00007fdfaae764e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#39 0x00007fdfa932d89b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#40 0x00007fdfa932fc96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#41 0x00007fdfa9383e33 in ?? () from /usr/lib/libQt5Core.so.5
#42 0x00007fdfa85dd9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#43 0x00007fdfa85ddce0 in ?? () from /usr/lib/libglib-2.0.so.0
#44 0x00007fdfa85ddd8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#45 0x00007fdfa938423f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#46 0x00007fdfa932b26a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#47 0x00007fdfa933320c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#48 0x00007fdfab95cb64 in kdemain () from /usr/lib/libkdeinit5_kded5.so
#49 0x00007fdfab5c9610 in __libc_start_main () from /usr/lib/libc.so.6
#50 0x0000000000400779 in _start ()

Thomas:  Shift-Alt-F12 doesn't appear to do anything but I am not overly confident it is being delivered properly.  Hitting it on the keyboard after login doesn't do anything to the screen nor does it allow Alt-F2 to function.

@Alexander: I'm quite angry about what I read here. The history of the bug report shows clearly that I:
* reproduced the bug
* investigated it
* came to a conclusion

From the timestamps you can even see that I spent about an hour just investigating this bug. I came to a conclusion which was correct at that time. The issue inside KWin was completely hidden due to the Qt bugs. It was not possible to reach the code of our own bug due to Qt causing a crash before. This is all documented in this bug report.

(In reply to Barry G from comment #52)
> Hitting it on the keyboard after login doesn't do anything to the screen nor does it allow Alt-F2 to function.

May be related to Bernd's observation

> And I get an additional crash in kded5 (which in any case completely utilizes one core):

(In reply to Bernd Amend from comment #51)
> #5  xcb_setup_vendor_end (R=R@entry=0x0) at xproto.c:869
> #6  0x00007fdfa5398119 in xcb_setup_pixmap_formats_iterator (R=R@entry=0x0)
> at xproto.c:892
> #7  0x00007fdfa5398159 in xcb_setup_roots_iterator (R=0x0) at xproto.c:909
> #8  0x00007fdfa7906808 in NETRootInfo::NETRootInfo(xcb_connection_t*,
> QFlags<NET::Property>, QFlags<NET::Property2>, int, bool) () from
> /usr/lib/libKF5WindowSystem.so.5

This is a related crash and like for KWin, we'll have to figure what makes the malicious randr call in kded5 (and we may safely assume it's not kwin this time ;-)

Can you debug it as explained in comment #35 and #37 (or can you, Barry)?

I can't seem to hit anything bad (after repeating comment #35 targeting kded5):
Breakpoint 13, 0x00007fffea9c4d10 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*)@plt () from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.

Breakpoint 30, 0x00007fffea9cb940 in QXcbConnection::createScreen(QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*) () from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.

Breakpoint 12, 0x00007fffea9c3f70 in QXcbScreen::QXcbScreen(QXcbConnection*, QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*, QString)@plt ()
   from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.

Breakpoint 33, 0x00007fffea9e1330 in QXcbScreen::QXcbScreen(QXcbConnection*, QXcbVirtualDesktop*, unsigned int, xcb_randr_get_output_info_reply_t*, QString) ()
   from /usr/lib/libQt5XcbQpa.so.5
(gdb) continue
Continuing.
Error in re-setting breakpoint 36: No source file named �O.
Could not find drkonqi at /usr/lib/drkonqi
Qt: Session management error: networkIdsList argument is NULL
klauncher not running... launching kdeinit
kbuildsycoca5 running...
kf5.kded: kded module "proxyscout" has already been found using JSON metadata, please don't install the now unneeded .desktop file ("kded/proxyscout.desktop").
[at this point it appears to run forever in the main loops]

Note this box is causing me issues :-)  Apparently everything is too new.  I am trying to get six monitors going on two gtx 980s and I have tried and failed the following methods:
1) Using xf86-video-nouveau doesn't support the NV124 (yet) so it doesn't work
2) Using modesetting/KMS driver single single card works but I hang at login much like this bug
3) Using modesetting/KMS driver with dual cards causes Xorg to segfault on a call to OsLookupColor+0x139 (still investigating this one)
4) Using nvidia driver with dual cards hits this bug

I have two working configurations
1) Single card with nvidia driver works (nvidia-settings -> configure one card only)
2) Dual cards with nvidia driver and Xinerama turned off works (two separate display servers)

Just to make life more fun this is an EFI system so if I switch to the nvidia driver I lose the console since nvidia kernel driver doesn't support efifb yet AFAIK.

I noticed on Martin's blog some qdbus commands to talk to kwin.  Would there be anything of value there to debug the hanging I am getting after login?

Thanks for the help

I pretty much see the same behaviour as Barry.
But I am not sure how to run kded5 in a context that results in the crash.
The crash also does not occur all the time, most of the time nothing happens (except for the endless loop).

I only have a 4k MST monitor and I did not find any solution to run it without Xinerama.

If the main loop is running forever, things simply run and you're not hitting Bernds segfault from comment #51 (sorry, no idea how to produce the segfault - kded5 ran ok here. It's however a daemon keeper, so some plugin will have caused that)

An endless main loop is btw. not a problem, but if a function enters an infinite loop (or recursion) things go south. (The segfault backtrace *may* be red herring in case the process was killed for an infinite recursion and running out of resources in eg. another thread)

@Barry
You can try qdbus on pretty much every KDE process, just to check whether it responds (if one doesn't, there's your problem)
Aside KWin that would be kded5, plasmashell, krunner and ksmserver - maybe also any "ksplash*" process running (you could also just try to kill the latter) and kglobalaccled5

If everything responds, CPU load of process is interesting - if anything maxes out its core, there's  your likely culprit and is worth being backtraced in gdb (bt, continue, bt, continue, ... see whether it's hanging somehere)

If there's no suspicious process and killing ksplash* doesn't get you ahead, there may be a deadlock (some process waiting for some external event) - and unfortunately that means gdb inspecting each forementioned process one-by-one.

Thomas,

I couldn't get kded5 to die except on first boot.  Using that information, I booted the box to sddm and then logged in over ssh and ran the following command:

while true; do KDED_PID="$(ps auxwwf | grep kded5 | grep -v grep | awk '{print $2}')" ; if [ -n "$KDED_PID" ]; then gdb -p $KDED_PID; fi;  done

This obviously sits waiting for kded5 to show up.  After that, I attempted to login.  gdb hit and grabbed the first kded5 process on the box.  I did the rbreak xcb_randr_.* and continued it.

I hit this:
Breakpoint 9, 0x00007f1d239b82d0 in xcb_randr_query_version@plt () from /usr/lib/qt/plugins/kded_powerdevil.so
(gdb) thread apply all bt 100

Thread 2 (Thread 0x7f1d2a1c7700 (LWP 18058)):
#0  0x00007f1d3fdf618d in poll () from /usr/lib/libc.so.6
#1  0x00007f1d3f2e99f2 in ?? () from /usr/lib/libxcb.so.1
#2  0x00007f1d3f2eb56f in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#3  0x00007f1d2c52fca9 in ?? () from /usr/lib/libQt5XcbQpa.so.5
#4  0x00007f1d40174a9e in ?? () from /usr/lib/libQt5Core.so.5
#5  0x00007f1d3d7344a4 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007f1d3fdff13d in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7f1d41a3b800 (LWP 18052)):
#0  0x00007f1d239b82d0 in xcb_randr_query_version@plt () from /usr/lib/qt/plugins/kded_powerdevil.so
#1  0x00007f1d239cd15f in ?? () from /usr/lib/qt/plugins/kded_powerdevil.so
#2  0x00007f1d239c4553 in PowerDevilUPowerBackend::init() () from /usr/lib/qt/plugins/kded_powerdevil.so
#3  0x00007f1d2377b747 in PowerDevil::Core::loadCore(PowerDevil::BackendInterface*) () from /usr/lib/libpowerdevilcore.so.2
#4  0x00007f1d239b994f in ?? () from /usr/lib/qt/plugins/kded_powerdevil.so
#5  0x00007f1d40384eb1 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#6  0x00007f1d3e9a300c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#7  0x00007f1d3e9a84e6 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#8  0x00007f1d4035589b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#9  0x00007f1d40357c96 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#10 0x00007f1d403abe33 in ?? () from /usr/lib/libQt5Core.so.5
#11 0x00007f1d3ca099fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007f1d3ca09ce0 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007f1d3ca09d8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#14 0x00007f1d403ac23f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#15 0x00007f1d4035326a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#16 0x00007f1d4035b20c in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#17 0x00007f1d2c9efb64 in kdemain () from /usr/lib/libkdeinit5_kded5.so
#18 0x000000000040856a in ?? ()
#19 0x000000000040585f in main ()
(gdb) continue

Breakpoint 19, 0x00007f1d239b8d40 in xcb_randr_query_version_reply@plt () from /usr/lib/qt/plugins/kded_powerdevil.so
(gdb) continue
Continuing.
[Thread 0x7f1d2a1c7700 (LWP 18058) exited]
[New Thread 0x7f1d2a1c7700 (LWP 18229)]
warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/libQt5XcbQpa.so.5"
[Thread 0x7f1d41a3b800 (LWP 18052) exited]
[Inferior 1 (process 18052) exited with code 01]
(gdb) 

Please tell me this is as good as I hope it is?

No clue why this only hits on the first run of the first login.  Maybe someone else knows that.

P.S. Note to anyone trying to reproduce this: I had to first run (as root):
echo 0 > /proc/sys/kernel/yama/ptrace_scope
or I could not attach gdb to pids.

(In reply to Barry G from comment #58)
> Please tell me this is as good as I hope it is?

Yes, is =)
bug #352462

Hi,
Purpose of this comment is just to put more data. (based on last comments it seems that you know all of it).
I have configuration (xorg.conf below):
1x ATI / AMD Radeon card (radeon module)
1x Intel HD card (i915 module)

I'm using 3 monitors, 2 monitor are connected to ATI/AMD card and one monitor is connected to Intel HD card. In my environment it is 100% reproducible.
randr extension is not working for me at all. (since comment #1 you know it is randr issue :-)).

user1@PC-1:~ $ xrandr 
RandR extension missing


I tried to reproduce the bug in home, but everything is working on my home Laptop.
Home config:
- 2 monitors, firs is internal laptop screen, second is external monitor connected via DP.
- Intel HD4400  (i915 module)

randr is also working perfectly, with xinerama option. 

Problem occurs only if you have 2 different graphic cards in your computer ?
Later I will check if this will help (but probably this would not help :-)).

Section "Extensions"
 Option "Composite" "Enable"
 Option "RANDR" "Enable"
EndSection



Section "ServerLayout"
    Identifier "Layout0"
    Screen 0 "Screen0" 0 0 
    Screen 0 "Screen1" RightOf "Screen0"
    Screen 0 "Screen2" LeftOf "Screen0" 
    InputDevice "Keyboard0" "CoreKeyboard"
    InputDevice "Mouse0" "CorePointer"
    Option "Xinerama" "1"
EndSection

Section "Files"
EndSection

Section "InputDevice"
# generated from default
    Identifier "Mouse0"
    Driver "mouse"
    Option "Protocol" "auto"
    Option "Device" "/dev/psaux"
    Option "Emulate3Buttons" "no"
    Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
# generated from default
    Identifier "Keyboard0"
    Driver "kbd"
EndSection

Section "Monitor"
    Identifier "Monitor0"
    VendorName "Unknown"
    ModelName "Unknown"
    HorizSync 24.0 - 83.0
    VertRefresh 43.0 - 72.0
    Option "DPMS"
EndSection

Section "Monitor"
    Identifier "Monitor1"
    VendorName "Unknown"
    ModelName "Unknown"
    HorizSync 24.0 - 83.0
    VertRefresh 43.0 - 72.0
    Option "DPMS"
EndSection

Section "Monitor"
    Identifier "Monitor2"
    VendorName "Unknown"
    ModelName "Unknown"
    HorizSync 24.0 - 83.0
    VertRefresh 43.0 - 72.0
    Option "DPMS"
EndSection

Section "Device"
    Identifier  "Device0"
    Driver      "radeon"
    VendorName  "ATI"
    BoardName   "Radeon"
    BusID       "PCI:1:0:0"
    Screen      0
EndSection

Section "Device"
    Identifier  "Device1"
    Driver      "radeon"
    VendorName  "ATI"
    BoardName   "Radeon"
    BusID       "PCI:1:0:0"
    Screen      1
EndSection

Section "Device"
    Identifier	 "Device2"
    Driver       "intel"
    VendorName   "Intel"
    BoardName    "INTEL"
    BusID        "PCI:0:02:0"
    Screen       0
    option       "HotPlug" "1"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "Device0"
    Monitor "Monitor0"
    DefaultDepth 24
    
    SubSection "Display"
        Depth 24
    EndSubSection
EndSection

Section "Screen"
    Identifier "Screen1"
    Device "Device1"
    Monitor "Monitor1"
    DefaultDepth 24
    
    SubSection "Display"
        Depth 24
    EndSubSection
EndSection

Section "Screen"
    Identifier "Screen2"
    Device "Device2"
    Monitor "Monitor2"
    DefaultDepth 24
    
    SubSection "Display"
        Depth 24
    EndSubSection
EndSection

Thomas,

I am back with more "help".  First thing I noticed is that kwin 5.4.1 hit Arch recently and I noticed kwin_x11 started crashing again.  Is the patch in comment #40 making its way into the repo?

I have also been trying to actually get stuff running.  I hacked on powerdevil some in an attempt to block it from making randr calls.  Right now my system is running with the following patches:
https://github.com/smartiq/kde5_dual_video_cards/blob/master/packages/kwin/fix_kwin_crash.patch
https://github.com/smartiq/kde5_dual_video_cards/blob/master/packages/powerdevil/pd_no_randr.patch

In an attempt to feed you guys more consistent information I also wrote a small script to try to capture the state of my KDE:
https://github.com/smartiq/kde5_dual_video_cards/blob/master/debug_script/debug_kde.sh

Here is the first run of it on my system with both patches applied:
https://raw.githubusercontent.com/smartiq/kde5_dual_video_cards/master/debug_script/output/debug_2015-09-12-12%3A43%3A37.txt

I have verified by kded5 isn't hitting xcb_randr calls anymore, but my KDE still doesn't load to the desktop.

I am worried I am hitting some sort of deadlock because the org.kde.kded5 and the org.kde.StatusNotifierWatcher are both not responding.  kded5 is in a Mutex::lock().

Let me know if I can expand my script to give more information that would be helpful,

Thanks

(In reply to Barry G from comment #61)
> Is the patch in comment #40 making its way into the repo?
5.4.1 was tagged before, sorry. (An it still needs to be submitted as well ;-)

> I have verified by kded5 isn't hitting xcb_randr calls anymore, but my KDE
> still doesn't load to the desktop.

 
> I am worried I am hitting some sort of deadlock because the org.kde.kded5
> and the org.kde.StatusNotifierWatcher are both not responding.  kded5 is in
> a Mutex::lock().

Same process, I guess the kscreen2 dameon will keep it in dead lock mode - just disable it (in kcmshell5 kded)

No guarantee on the desktop, though. We'll require better default sizes in kwin and /likely) libkscreen, latter possibly impacting plasmashell's desktop window size.

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

Git commit 0302b97aea6a686b9d62c2d8c63b736cb9d93128 by Thomas Lübking.
Committed on 29/09/2015 at 21:02.
Pushed by luebking into branch 'master'.

prevent calling xrandr w/o extension available
FIXED-IN: 5.5
REVIEW: 125074

M  +4    -0    screens_xrandr.cpp
M  +27   -26   useractions.cpp

http://commits.kde.org/kwin/0302b97aea6a686b9d62c2d8c63b736cb9d93128

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

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