SIGSEGV (null-deref) in IO thread, reproducible via herdr session restore — same offset across all occurrences

[thomas-trijindev]

Version

ghostty 1.3.1-2 (Arch Linux, official extra repo build)

System

• OS: Arch Linux, kernel 7.1.9-arch1-2
• WM: Hyprland 0.56.2-1
• GPU stack: mesa 1:26.2.1-1
• GTK: gtk4 1:4.22.4-1, glib2 2.88.3-1
• Launched via ghostty --gtk-single-instance=true --working-directory=...
• Relevant config: async-backend = epoll (set explicitly, per
  High iowait and general slowness when using io_uring #3224 — the crashing
  thread is the IO thread this setting controls)

What happened

ghostty's io thread segfaults with SIGSEGV shortly after a terminal
multiplexer (herdr, https://github.com/herdrdev/herdr) attaches and renders
a restored multi-pane session inside a ghostty surface.

This is not a one-off: it is the only kind of crash systemd-coredump has
ever recorded for ghostty on this machine, and it has now happened 4 times
over 3 days, every time at the identical binary offset:

#0  0x0000558c5ce5190d n/a (ghostty + 0x151c90d)   # 2026-08-31 10:03
#0  0x000056361053990d n/a (ghostty + 0x151c90d)   # 2026-08-31 10:12
#0  0x0000559ee33fe90d n/a (ghostty + 0x151c90d)   # 2026-08-29 (13:39)
#0  0x000055971cab290d n/a (ghostty + 0x151c90d)   # 2026-08-29 (13:47)

Register/disassembly at the fault (from the 2026-08-31 core):

=> 0x558c5ce5190d:  mov    0x108(%r14),%rcx
r14 = 0x0

i.e. a null pointer is dereferenced at a fixed struct offset (+0x108).
si_code is SEGV_MAPERR. rbp is 0 at the point of fault, so the release
build's stripped/frame-pointer-omitted binary doesn't leave much for further
unwinding without ghostty's own debug symbols (Arch's debuginfod only serves
Mesa/GLX symbols, not ghostty's).

Timing correlation with the trigger

For all 4 crashes, a herdr client's own logs show it starting up and then
being torn down again within well under a second — right as it renders a
restored multi-pane session (5 panes / 2 workspaces) in one burst. The
timestamps match the kernel-logged SIGSEGV to the millisecond in every case,
e.g.:

kernel: io[20123]: segfault at 108 ip 0000558c5ce5190d ... in ghostty
herdr:  2026-08-31T02:03:21Z  client connected client_id=2 ... render_encoding=SemanticFrame
herdr:  2026-08-31T02:03:22Z  client detached/disconnected client_id=2

(herdr log timestamps are UTC; the kernel/coredump timestamps above are
local +08 — they refer to the same instant.)

Importantly, the herdr server was not restarting between these events —
one long-lived server process served all of the attach attempts below,
including the one that succeeded, with identical window geometry
(cols=106 rows=57) and the same render_encoding=SemanticFrame. So
"is a herdr server already running" is not what distinguishes crash from
non-crash.

What does appear to correlate is how long the ghostty window had been
open before herdr's first attach inside it:

ghostty surface	window uptime before herdr's first attach	result
PID 4887	~49 min	crash (+0x151c90d)
PID 27119	~9 min	crash (+0x151c90d)
(next surface, opened immediately after)	~3 sec	no crash

Both crashes were herdr's first attach into a ghostty window that had
already been sitting open for several minutes; the one clean attach
observed so far was into a window opened only seconds earlier. I've since
confirmed this is reliably reproducible: opening a fresh ghostty window,
leaving it idle for several minutes, then running herdr for the first
time in that window reproduces the crash on demand, while attaching
immediately after opening the window does not.

Steps to reproduce (confirmed reliable)

1. Open a ghostty window with --gtk-single-instance=true.
2. Leave it open/idle for at least several minutes without touching it.
3. Run herdr (0.8.2) inside it for the first time since it opened — on
   attach it restores a persisted multi-pane session and issues a
   full-session redraw immediately.
4. ghostty's IO thread segfaults almost immediately on that attach.

Attaching immediately after opening a fresh window does not trigger it —
idle time appears to be the deciding factor.

I could not narrow this to a single escape sequence — I don't have ghostty
debug symbols to identify the parsing function, and I don't want to guess.
Flagging the async-backend = epoll setting in case that path is less
exercised than the default backend.

Other

• No OOM, no GPU driver errors, no ghostty/herdr package updates coincided
  with any of the 4 crashes (both packages installed 2026-08-28, unchanged
  since).
• Happy to attach a core file or run further gdb sessions if useful.

[pluiedev]

Again we don't accept LLM-filed bug reports with no attempt at human interpretation. You're not respecting our time.

[pluiedev]

!denounce No human in the loop