Using plasma5-workspace-5.4.3-1.1.x86_64 on openSUSE Tumbleweed x86_64. When trying to lock the screen the image freezes - no lock screen appears and I am only able to move the mouse but not input anything. Switching to another VT and running 'top' shows that I have 7-8 coredumpctl processes running at the same time. I'm running a W541 Lenovo Laptop using the Intel video card only - neither nouveau nor the nvidia proprietary drivers are installed. Reproducible: Always Steps to Reproduce: Try to lock the screen. Here's a core dump summary from coredumpctl PID: 29049 (kscreenlocker_g) UID: 1000 (robert) GID: 100 (users) Signal: 6 (ABRT) Timestamp: Thu 2015-12-17 14:21:36 EET (22min ago) Command Line: /usr/lib64/libexec/kscreenlocker_greet --immediateLock --ksldfd 52 Executable: /usr/lib64/libexec/kscreenlocker_greet Control Group: /user.slice/user-1000.slice/session-13.scope Unit: session-13.scope Slice: user-1000.slice Session: 13 Owner UID: 1000 (robert) Boot ID: fa49e85f2ebf4f31b00f5e04300e9e6d Machine ID: 87f0790206514af7a87d17a290547703 Hostname: rombert.corp.adobe.com Coredump: /var/lib/systemd/coredump/core.kscreenlocker_g.1000.fa49e85f2ebf4f31b00f5e04300e9e6d.29049.1450354896000000.xz Message: Process 29049 (kscreenlocker_g) of user 1000 dumped core. The gdb backtrace shows #0 0x00007f3e830e8d38 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f3e830ea18a in __GI_abort () at abort.c:78 #2 0x00007f3e8387482e in qt_message_fatal (context=..., message=<synthetic pointer>) at global/qlogging.cpp:1578 #3 QMessageLogger::fatal (this=this@entry=0x7fffa1142d60, msg=msg@entry=0x7f3e72e093e8 "QXcbConnection: Could not connect to display %s") at global/qlogging.cpp:781 #4 0x00007f3e72d93ad0 in QXcbConnection::QXcbConnection (this=0x237a920, nativeInterface=0x2374420, canGrabServer=<optimized out>, defaultVisualId=<optimized out>, displayName=0x0) at qxcbconnection.cpp:511 #5 0x00007f3e72d99125 in QXcbIntegration::QXcbIntegration (this=<optimized out>, parameters=..., argc=@0x7fffa11431fc: 4, argv=0x7fffa11434e8) at qxcbintegration.cpp:177 #6 0x00007f3e7306e4cd in QXcbIntegrationPlugin::create (this=<optimized out>, system=..., parameters=..., argc=@0x7fffa11431fc: 4, argv=0x7fffa11434e8) at qxcbmain.cpp:50 #7 0x00007f3e83f8a1d2 in loadIntegration (argv=0x7fffa11434e8, argc=@0x7fffa11431fc: 4, parameters=..., key=..., loader=0x7f3e845d4bf0 <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>) at kernel/qplatformintegrationfactory.cpp:56 #8 QPlatformIntegrationFactory::create (platform=..., paramList=..., argc=@0x7fffa11431fc: 4, argv=argv@entry=0x7fffa11434e8, platformPluginPath=...) at kernel/qplatformintegrationfactory.cpp:73 #9 0x00007f3e83f956d2 in init_platform (argv=0x7fffa11434e8, argc=<optimized out>, platformThemeName=..., platformPluginPath=..., pluginArgument=...) at kernel/qguiapplication.cpp:1019 #10 QGuiApplicationPrivate::createPlatformIntegration (this=0x236c730) at kernel/qguiapplication.cpp:1176 #11 0x00007f3e83f965dd in QGuiApplicationPrivate::createEventDispatcher (this=<optimized out>) at kernel/qguiapplication.cpp:1193 #12 0x00007f3e83a5bfc6 in QCoreApplication::init (this=this@entry=0x7fffa11432b0) at kernel/qcoreapplication.cpp:768 #13 0x00007f3e83a5c026 in QCoreApplication::QCoreApplication (this=0x7fffa11432b0, p=...) at kernel/qcoreapplication.cpp:689 #14 0x00007f3e83f9811d in QGuiApplication::QGuiApplication (this=0x7fffa11432b0, argc=@0x7fffa11431fc: 4, argv=0x7fffa11434e8, flags=328961) at kernel/qguiapplication.cpp:558 #15 0x00000000004136f5 in ScreenLocker::UnlockApp::UnlockApp (this=0x7fffa11432b0, argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma-workspace-5.4.3/ksmserver/screenlocker/greeter/greeterapp.cpp:80 #16 0x000000000040dd43 in main (argc=4, argv=0x7fffa11434e8) at /usr/src/debug/plasma-workspace-5.4.3/ksmserver/screenlocker/greeter/main.cpp:58
are all backtraces like that? Question is whether the first crash looks the same, because "QXcbConnection: Could not connect to display" doesn't make any sense. Why should it not be able to connect to the XDisplay? Unrelated to that: you should never get more than 4 crashers and afterwards an error message should be shown telling you how to unlock the screen. On second thought: that might be new in 5.5
> Question is whether the first crash looks the same Yes, I just checked the first one for today and it has the same message. > Unrelated to that: you should never get more than 4 crashers and afterwards an error message should be shown telling you how to unlock the screen. On second thought: that might be new in 5.5 It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today
> It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today sorry about that :-( Positive: it shows that the investment in ensuring that doesn't happen was worth the effort. Could you please try to manually start /usr/lib64/libexec/kscreenlocker_greet --testing The question for me is whether that will also abort.
(In reply to Martin Gräßlin from comment #3) > > It might be new in 5.5, I don't get this behaviour and I have > 50 dumps for today > > sorry about that :-( Positive: it shows that the investment in ensuring that > doesn't happen was worth the effort. > > Could you please try to manually start > /usr/lib64/libexec/kscreenlocker_greet --testing > > The question for me is whether that will also abort. I will try do that. However I need to wait for the crash to happen again, and then I'll only be able to run this from another VT.
No need to wait for the crash to happen again. Just run it from a konsole in your X session.
(In reply to Martin Gräßlin from comment #5) > No need to wait for the crash to happen again. Just run it from a konsole in > your X session. Yes, it worked. However, locking the screen also worked fine after the last restart.
all right. I set to UPSTREAM as the crash happened deep down in Qt's interaction with XCB. There is not much we can do about that anyway. Feel free to add any new information you find. E.g. if it happens again and you notice a pattern. At the moment I assume that the problem was rather in X, like X session closing or not reacting on the socket.
For the record, when this problem happens I can work around it by manually killing another kscreenlocker-related process. I forgot its name, something related to 'backend' I think. So this might be a clue - that process might be holding on to a stale reference ( of something, I have no idea about X internals ) and killing it ( and probably it being restarted ) make the problem go away.
> I forgot its name, something related to 'backend' I think. kscreen_backend_launcher? > So this might be a clue - that process might be holding on to a stale reference Maybe it's holding an XServerGrab.
(In reply to Martin Gräßlin from comment #9) > > I forgot its name, something related to 'backend' I think. > > kscreen_backend_launcher? Yes, I think so.