Conversation
|
Crash analysis GDK tries to draw to a GdkWindow whose backing wl_surface has already been destroyed by gtk-layer-shell. The compositor sent zwlr_layer_surface_v1.closed when the KVM disconnected the output, gtk-layer-shell destroyed the wl_surface in response, but GDK still had a pending frame clock event that called gdk_window_begin_draw_frame() — which dereferences the now-dead proxy → SIGSEGV. Quit behaviour analysis In X11, a desktop window (GDK_WINDOW_TYPE_HINT_DESKTOP) is just an X11 window sitting at specific screen coordinates. When a monitor disappears (RandR event), the X server doesn't close or invalidate those windows. They just become "off-screen" orphans. GDK emits GdkScreen::size_changed, nemo-desktop's handler queues a layout update, and layout_changed explicitly destroys and recreates the windows at the right time. The windows persist throughout — which keeps GtkApplication's window reference alive, which keeps the process alive. In Wayland with layer-shell, the compositor is an active participant. When an output disappears, it sends zwlr_layer_surface_v1.closed to tell the client "this surface is gone." gtk-layer-shell handles that by destroying the GtkWindow from underneath nemo-desktop. GtkApplication then has no windows, and so it exits. |
Hold the application alive in Wayland mode when monitors disappear, so it can recover when the monitor returns, rather than exiting. Handle GdkDisplay::monitor-removed immediately, by destroying windows cleanly before gtk-layer-shell's closed handler fires, so there's no dangling surface for the frame clock to hit.
1 participant
Whenever we KVM switch away from the Wayland session, nemo-desktop either crashes, or quits.
We don't always get a stacktrace for the crash, because it sometimes quits first.