SUMMARY Twice in the past 4 hours, KDE desktop completely locked up (even the clock seconds were not updating). The mouse cursor was a hand as the trigger was grabbing the title bar of an emacs window and dragging between 2 physical screens. kwin_x11 was 100%. 2xCtrl+Alt+Bksp eventually gives a login; but I only get 1 of 10 virtual desktops. The Windows key wants to display the application menu; but only about 1/8" of the menu bottom appears. Very little looks right. A full reboot is required to clear the mess up. I know this is not yet enough info; but opening this issue to track any new lockups and maybe provide a hint to anyone else seeing this. STEPS TO REPRODUCE 1. Open file with emacs: "e file &" using: alias e='function _(){ emacs "$*" ; }; _' 2. grab emacs window title bar and drag with to another physical screen (I have 3 monitors) 3. seems to be a race condition at play since this is not easily repeatable. It may be that a konsole has a long running process with occasional output[1] as I drag the emacs window over it. Across physical displays was the case in both lockups; but it may just be dragging emacs over the konsole. Will add more each time this happens. [1] In both cases the long running process was a python script copying millions of rows into a PostgreSQL database; the COPY continued to completion, including table indexing. I monitored this via tty3, htop and ps... OBSERVED RESULT Total GUI lockup. Reboot required. EXPECTED RESULT No lockup SOFTWARE/OS VERSIONS Operating System: Mageia 10 KDE Plasma Version: 6.2.91 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.6.74-server-1.mga10 (64-bit) Graphics Platform: X11 Processors: 20 × 12th Gen Intel® Core™ i7-12700K Memory: 125.5 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT Manufacturer: Dell Inc. Product Name: XPS 8950 ADDITIONAL INFORMATION Dunno if related; but htop showed an xdg-open process in Z state along with kwin_x11 at 100% cpu.
Just experienced another lockup. This time, via tty3, issues sigkill to kwin_x11 which restarted it and restored my session with all apps still running. At least, there is an acceptable workaround...
This time, I was moving a firefox window from right-most display to middle one.
yet again. This time it occurred without moving a window. A python script was importing millions of records into postgres and likely writing status info to konsole. Moving windows may be coincidental to konsole output?
Created attachment 177968 [details] rpm -qa --last Again. This time, grabbed title bar of emacs window which was across middle/right screens boundary and barely moved it when the lockup occurred. Attaching output of recent "rpm -qa --last"; given the frequency of occurrence, guessing this started after 1/31/25 or 1/29/25 updates.
3rd time in a few minutes... strace shows nothing. Open to other debugging options... gdb: (gdb) bt full #0 0x00007f3045126b5f in QRect::operator&(QRect const&) const () at /lib64/libQt6Core.so.6 #1 0x00007f3048265814 in KWin::Window::nextInteractiveMoveGeometry(QPointF const&) const () at /lib64/libkwin.so.6 #2 0x00007f304826e681 in KWin::Window::updateInteractiveMoveResize(QPointF const&, QFlags<Qt::KeyboardModifier>) () at /lib64/libkwin.so.6 #3 0x00007f30482bb1c1 in KWin::X11Window::motionNotifyEvent(unsigned int, int, int, int, int, int) () at /lib64/libkwin.so.6 #4 0x00007f30482bbec9 in KWin::X11Window::windowEvent(xcb_generic_event_t*) () at /lib64/libkwin.so.6 #5 0x00007f30481297fe in KWin::Application::dispatchEvent(xcb_generic_event_t*) () at /lib64/libkwin.so.6 #6 0x00007f3044fb460f in QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long long*) () at /lib64/libQt6Core.so.6 #7 0x00007f303fae0f31 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /lib64/libQt6XcbQpa.so.6 #8 0x00007f303fae2446 in QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6XcbQpa.so.6 #9 0x00007f303fb021b7 in xcbSourceDispatch(_GSource*, int (*)(void*), void*) () at /lib64/libQt6XcbQpa.so.6 #10 0x00007f3043b03e21 in g_main_context_dispatch_unlocked () at /lib64/libglib-2.0.so.0 #11 0x00007f3043b06040 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 #12 0x00007f3043b06840 in g_main_context_iteration () at /lib64/libglib-2.0.so.0 #13 0x00007f30452a4b53 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Core.so.6 #14 0x00007f3044fc8e72 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /lib64/libQt6Core.so.6 #15 0x00007f3044fc48ba in QCoreApplication::exec() () at /lib64/libQt6Core.so.6 #16 0x000055f7cc6b8643 in main ()
Created attachment 177977 [details] bt full again... looks like mostly the same bt full. Another thing I'm noticing: a window which is behind others (maybe 1/2" visible) appears to be flickering. Will try to capture more details on next lockup.
I should note this issue only occurs when I grab the title bar of a window to move it either slightly, or to another monitor.
Created attachment 178616 [details] screenshot of flickering firefox nightly window When this lock occurs, after killing the process; some firefox windows show random firefox windows flickering within one firefox window -- cycling through multiple "windows" at fairly high speed. This image is the best representation I've captured. A video would better show what i s happening. Then, just moving the mouse over this window causes the flickering to stop and restore the window to normal. This issue occurs several times a day.
Adding the x11-only keyword