| Summary: | plasmashell repeatedly crashing on multi-monitor desktop, usually when monitors are waking up from a sleep state wl_registry#51: error 0: invalid global kde_output_device_v2 (124) | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Brent Spillner <spillner> |
| Component: | generic-crash | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | kdedev, nate, spillner |
| Priority: | NOR | Keywords: | multiscreen, wayland-only |
| Version First Reported In: | 6.5.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=507691 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
stderr output from a crash when running under GDB
GDB backtrace, unfortunately debugging symbols are stripped but crash seems to come from qwaylandeglwindow.cpp:120 |
||
|
Description
Brent Spillner
2025-11-21 21:52:03 UTC
plasmashell crashed again today; this time Chromium was not running, so there must be other causes. The error messages were a little different and seem to confirm that it's an issue with the set of available screens changing (e.g. when one screen resumes before another): kde.plasmashell: requesting unexisting screen available rect -1 kf.plasma.quick: Exposed with no visual parent. Window positioning broken. kde.plasmashell: requesting unexisting screen available rect -1 kde.plasmashell: requesting unexisting screen available rect -1 kde.plasmashell: requesting unexisting screen available rect -1 kde.plasmashell: requesting unexisting screen available rect -1 wl_registry#51: error 0: invalid global kde_output_device_v2 (158) warning: queue "mesa egl surface queue" 0x7f2fbc42e650 destroyed while proxies still attached: wp_presentation#43 still attached qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) The Wayland connection experienced a fatal error: Protocol error [1]+ Exit 255 plasmashell --replace (wd: ~) May be related to https://discuss.kde.org/t/abnormal-wake-up-after-lock-screen/39747/14 or https://bugs.kde.org/show_bug.cgi?id=447936. Thanks for the crash report. As the message at the top of the summary says, if something crashed, we need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ? Thanks. I avoid systemd so I don't have coredumpctl, and my coredumpsize ulimit in that session was zero anyway. However, plasmashell just crashed again, so I've restarted it under GDB (although my system package has debugging symbols stripped) and will share the dump from the next crash. The stderr output from this crash is pasted below; it looks like the "invalid global kde_output_device_v2" message is still the common denominator, with the crash sequence always unfolding the same way from that point on, although there may be several different preceding trigger paths: [21023:21197:1126/062516.386730:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. [21023:21197:1126/062516.386791:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. [21023:21197:1126/062516.386818:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. [21023:21197:1126/062516.386872:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. [21023:21197:1126/062516.386895:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. [21023:21197:1126/062516.386914:ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:526] SharedImageManager::ProduceMemory: Trying to Produce a Memory representation from a non-existent mailbox. wl_registry#51: error 0: invalid global kde_output_device_v2 (208) warning: queue "mesa egl surface queue" 0x7f9a2cb1ef00 destroyed while proxies still attached: wp_presentation#43 still attached qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) The Wayland connection experienced a fatal error: Protocol error Created attachment 187326 [details]
stderr output from a crash when running under GDB
(In reply to TraceyC from comment #3) > Thanks for the crash report. As the message at the top of the summary says, > if something crashed, we need a backtrace of it so we can figure out what's > going on. Can you please attach a backtrace of the crash using the > coredumpctl command-line program, as detailed in > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ? > > Thanks. plasmashell crashed again today, but I just realized that these particular crashes will /never/ generate a core because it shuts itself down and exits "normally" from the OS perspective, albeit with a non-zero status code, i.e. it's invoking exit(255) instead of raising an uncaught signal. Today's crash was again while the monitors were waking up from sleep, and with a very similiar stderr trace to all of the previous instances (attached). Of note, in case it wasn't clear from my earlier reporting, this is not a deterministic failure; the monitors wake successfully dozens of times between every pair of crashes, and as far as I can recall I've never had two crashes within 24-48 hours of each other (so there may be some resource that's being gradually exhausted). Anyway, I've restarted it, again under GDB, with a breakpoint on exit() this time, and I'll gcore when it quits on me again, but I'm skeptical that will add much value in troubleshooting a fault of this nature in a multithreaded program. Trace from the newest crash pasted below; it looks like the failures are being triggered (or at least recognized) within the !sizeWithMargins.isEmpty() && !m_waylandEglWindow && create && mSurface QMetaCallEvents branch of QWaylandEglWindow::updateSurface(). Specifically, the eglCreateWindowSurface() call at https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/wayland/plugins/hardwareintegration/wayland-egl/qwaylandeglwindow.cpp#L120 is ultimately triggering QWaylandIntegration::clientBufferIntegration() -> QWaylandIntegration::Initialize() -> QWaylandDisplay::initEventThread() -> checkWaylandError(), and then returning a failure code back up the stack. I don't know enough about wayland-egl to know what's causing the failure, but perhaps QMetaCallEvents are being delivered out-of-order from the EGL backend's perspective? Are there any good tools for tracing that event queue? wl_registry#51: error 0: invalid global kde_output_device_v2 (168) [Thread 0x7fffec80f6c0 (LWP 22651) exited] warning: queue "mesa egl surface queue" 0x7fff58509540 destroyed while proxies still attached: wp_presentation#43 still attached qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) [Thread 0x7fff567fc6c0 (LWP 28719) exited] [Thread 0x7fff56ffd6c0 (LWP 28718) exited] [Thread 0x7fff577fe6c0 (LWP 28717) exited] [Thread 0x7fff57fff6c0 (LWP 28716) exited] [Thread 0x7fff6512f6c0 (LWP 28715) exited] [Thread 0x7fffa2ffd6c0 (LWP 28714) exited] [Thread 0x7fffbeffd6c0 (LWP 28713) exited] The Wayland connection experienced a fatal error: Protocol error Thread 1 "plasmashell" hit Breakpoint 4.1, 0x00007ffff3b76e10 in _exit () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff3b76e10 in _exit () at /lib64/libc.so.6 #1 0x00007ffff56671b7 in QtWaylandClient::QWaylandDisplay::checkWaylandError() () at /usr/lib64/libQt6WaylandClient.so.6 #2 0x00007ffff445d772 in QObject::event(QEvent*) () at /usr/lib64/libQt6Core.so.6 #3 0x00007ffff6ef4238 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt6Widgets.so.6 #4 0x00007ffff43ed898 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt6Core.so.6 #5 0x00007ffff43f146e in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt6Core.so.6 #6 0x00007ffff477e417 in ??? () at /usr/lib64/libQt6Core.so.6 #7 0x00007ffff2842ad6 in ??? () at /usr/lib64/libglib-2.0.so.0 #8 0x00007ffff2845bdf in ??? () at /usr/lib64/libglib-2.0.so.0 #9 0x00007ffff284630c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #10 0x00007ffff477e5b8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6 #11 0x00007ffff43fc296 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt6Core.so.6 #12 0x00007ffff43f61ac in QCoreApplication::exec() () at /usr/lib64/libQt6Core.so.6 #13 0x000000000042e391 in ??? () #14 0x00007ffff3ab6d14 in __libc_start_call_main () at /lib64/libc.so.6 #15 0x00007ffff3ab6dc6 in __libc_start_main_impl () at /lib64/libc.so.6 #16 0x000000000042e4a1 in ??? () Created attachment 187415 [details]
GDB backtrace, unfortunately debugging symbols are stripped but crash seems to come from qwaylandeglwindow.cpp:120
Thanks for the backtrace and the additional detail. I wouldn't worry about the missing symbols at this point, since this is a protocol error. *** This bug has been marked as a duplicate of bug 507691 *** |