Renderer segfault when fullscreen window moves to smaller monitor (GTK/Wayland, multi-monitor)

[JoeMcB]

Summary

Ghostty consistently crashes with a segfault in the renderer thread when a fullscreen window is moved to a smaller monitor. This has occurred 3 times in the past week, all with an identical crash signature.

Steps to Reproduce

1. Run Ghostty fullscreen on a 5120x2880 external monitor
2. Move/drag the fullscreen window to the smaller built-in laptop display (2880x1920)
3. Ghostty crashes immediately

This happens consistently — every time a fullscreen Ghostty window transitions between monitors of different resolutions.

Crash Log

Three crashes in the past week, all at the same instruction pointer with identical machine code:

Apr 17 22:37:30 kernel: renderer[2077006]: segfault at 7a5d34fef190 ip 0000000002a6c898 sp 00007a5cdd7ddf10 error 4 in ghostty[1a6d898,228d000+b3c000] likely on CPU 12 (core 4, socket 0)

Apr 21 16:54:46 kernel: renderer[14599]: segfault at 75997d54a0b8 ip 0000000002a6c898 sp 00007598e7fe2f10 error 4 in ghostty[1a6d898,228d000+b3c000] likely on CPU 10 (core 2, socket 0)

Apr 22 08:29:05 kernel: renderer[376681]: segfault at 7592b8b69190 ip 0000000002a6c898 sp 000075921bfe2f10 error 4 in ghostty[1a6d898,228d000+b3c000] likely on CPU 0 (core 0, socket 0)

Faulting instruction (identical in all three):

Code: 66 0f 11 42 10 66 0f 11 02 48 c7 82 d0 00 00 00 00 00 00 00 8b 0f 85 c9 0f 8e e1 02 00 00 49 89 d7 49 89 fd 45 31 f6 45 31 e4 <44> 3b 26 0f 8d cc 02 00 00 49 63 d4 49 8b 7d 08 4c 01 ef 4c 8b 4e

• Error code 4 = read access to unmapped user-space page
• The crash always occurs in the renderer thread, not the main thread

Contextual Clues from Logs

The Apr 22 crash is the most informative. At the exact same timestamp:

• XWAYLAND: mode -1x-1 is not available — an invalid display mode was encountered
• Slack logged DISPLAY_METRICS_CHANGED and DISPLAY_ADDED — confirming a monitor configuration change event
• Ghostty logged unimplemented action=.cell_size immediately before the crash
• Ghostty logged adjusting page capacity 7 seconds before the Apr 21 crash

This strongly suggests a race condition or use-after-free in the renderer during a display/resize event triggered by monitor switching.

Environment

Ghostty:        1.3.1 (snap, stable channel)
Renderer:       renderer.generic.Renderer(renderer.OpenGL)
GTK:            4.14.5
libadwaita:     1.5.0
Zig build:      0.15.2 (ReleaseFast)
libxev:         io_uring
Display:        Wayland (GNOME Shell, XWayland available)
Kernel:         6.17.0-22-generic (Linux)
Hardware:       Framework Laptop 13, AMD Ryzen AI 300 Series
GPU:            AMD integrated

Monitor setup (3 monitors):

• eDP-1: 2880x1920 (built-in laptop display)
• DP-3: 5120x2880 (external)
• DP-4: 5120x2880 (external)

Additional Notes

• No coredumps were captured (snap packaging appears to prevent coredumpctl from collecting them)
• Happy to reproduce with GHOSTTY_LOG=debug or a debug build if that would help narrow down the specific renderer code path

[pluiedev]

Sorry, but we can't read raw machine code without any debug symbols. The cell_size thing is a red herring and is only an internal warning — the XWayland log is interesting, though. I can't think of any reason why it would be there.

[jbr870]

Another data point on 1.3.1 (snap, stable) with the same trigger — a window moving between monitors of different resolution — but a different crash signature and no fullscreen involved. Possibly the same underlying bug manifesting differently.

Symptom: all four open windows vanished at once. They were all in a single ghostty process, so one heap corruption took the lot.

Crash line — glibc abort, not SIGSEGV:

Jul 30 10:46:33 ghostty[61305]: warning(gtk_ghostty_application): unimplemented action=.cell_size
Jul 30 10:51:51 ghostty[61305]: warning(gtk_ghostty_application): unimplemented action=.cell_size
Jul 30 10:53:48 ghostty[61305]: info(opengl): loaded OpenGL 4.5
Jul 30 10:53:48 ghostty[61305]: warning(gtk_ghostty_application): unimplemented action=.cell_size
Jul 30 10:55:07 ghostty[61305]: free(): invalid pointer
Jul 30 10:55:08 systemd[15013]: snap.ghostty.ghostty-....scope: Consumed 1h 13min 18.074s CPU over 1h 35min 12.995s wall clock time, 1.3G memory peak.

free(): invalid pointer is glibc detecting heap corruption and calling abort() — consistent with the double-free / use-after-free hypothesis in the OP, but caught by the allocator rather than by the MMU. Note the three cell_size events in the nine minutes before the abort; each one lines up with a monitor/scale change as I dragged windows around.

Difference from the OP: the window was not fullscreen. Just an ordinary window dragged from a 3840x1600 monitor to a 3840x2160 one.

Environment

• Ghostty 1.3.1, snap rev 820, latest/stable, ReleaseFast, Zig 0.15.2
• Renderer: renderer.generic.Renderer(renderer.OpenGL), libxev io_uring, fontconfig_freetype
• GTK 4.14.5 (build == runtime), libadwaita 1.5.0
• Ubuntu, kernel 7.0.0-28-generic, GNOME on Wayland (XDG_SESSION_TYPE=wayland, XDG_CURRENT_DESKTOP=ubuntu:GNOME)
• NVIDIA, pci id 10de:2204
• Monitors: 3840x1600 + 3840x2160

Possibly relevant — fractional scaling is enabled.

$ gsettings get org.gnome.mutter experimental-features
['scale-monitor-framebuffer', 'xwayland-native-scaling']

scale-monitor-framebuffer turns on fractional scaling. (gnome-shell separately logs Unknown experimental feature 'xwayland-native-scaling', so that second one isn't actually supported by this mutter.) Given the OP's XWAYLAND: mode -1x-1 is not available line, and cell_size warnings immediately preceding both crashes, monitor scale changes look like the common thread.

Ghostty also sets these itself at startup, which seems worth noting next to a compositor doing fractional scaling:

warning(gtk_ghostty_application): setting GDK_DEBUG=gl-disable-gles,gl-no-fractional,vulkan-disable
warning(gtk_ghostty_application): setting GDK_DISABLE=color-mgmt

And EGL warnings on every start, presumably snap confinement:

libEGL warning: pci id for fd 10: 10de:2204, driver (null)
libEGL warning: egl: failed to create dri2 screen

On debug symbols: understood re: the earlier comment — the snap is ReleaseFast with no symbols, so I have no useful backtrace either. But free(): invalid pointer does at least narrow it to allocator-detected heap corruption rather than a null or wild read. This has now happened to me at least three times, always around a monitor move, so I can probably reproduce on demand — happy to run a debug build under gdb if that would help. Just say what you'd want captured.

[pluiedev]

If your agent is so cool and hip and knows how to diagnose crashes this well, then tell it to send patches. Otherwise tell it to shut its trap.