Ghostty 1.3.1-2 SIGSEGV in io thread ~9s after launch — NULL pointer deref at +0x108 (linked-list remove)

[tangivis]

"## Summary\n\nGhostty 1.3.1-2 (Arch) crashes with SIGSEGV in the io thread roughly 9 seconds\nafter every launch. The fault is a NULL pointer dereference at offset +0x108\ninside an intrusive linked-list remove operation. The crash has been\nreproducible at the exact same offset (ghostty+0x151c90d) for the past five\ndays on the same machine and binary.\n\n## Reproduction\n\nJust launch ghostty. No special flags needed — the crash happens through the\nnormal xdg-terminal-exec flow used by Hyprland:\n\n\n/usr/bin/ghostty --gtk-single-instance=true --working-directory=/home/tang\n\n\nRe-launching after a crash immediately reproduces: the second instance dies at\nthe same offset within ~7 seconds.\n\n## System\n\n- ghostty 1.3.1-2 (Arch extra)\n- Linux 6.x, AMD x86-64\n- Hyprland + xdg-terminal-exec via uwsm\n- binary BuildID 36aeb61c844ddf428f960758acdb8b37f30d7e31\n\n## Evidence\n\ncoredumpctl info for one occurrence:\n\n\nPID: 7365 (ghostty)\nTID: 1572855 (io)\nSignal: 11 (SEGV) si_code: SEGV_MAPERR\nTimestamp: Sun 2026-08-23 11:40:09 JST\nCommand Line: /usr/bin/ghostty --gtk-single-instance=true --working-directory=/home/tang\n\n\nKernel log around the same event:\n\n\nio[1572855]: segfault at 108 ip 000055d8d620c90d sp 00007f750303cbf0 error 4\n in ghostty[151b90d,55d8d5ecd000+88d000]\n\n\nRegisters from the core (gdb info registers, crashing thread):\n\n\nrip 0x55d8d620c90d (= ghostty + 0x151c90d)\nr14 0x0 <-- NULL pointer passed as the node\nr15 0x7f750303ccd8\nr13 0x7f750303ccb8\nrbx 0x7f7528227040\nrbp 0x24 <-- likely Zig async resume-point discriminant\nrdi 0x7f75030451f8 <-- list head\nrsi 0x55d9083ef8e8\n\n\nDisassembly around the fault (the function starts at ghostty+0x151c820):\n\n\n151c8ff: cmp 0x8(%rdi),%r14 ; head->next == r14 ?\n151c903: jne 151c90d\n151c905: movq $0x0,0x8(%rdi) ; head->next = null\n151c90d: mov 0x108(%r14),%rcx ; *** FAULT: r14 = 0 ***\n151c914: mov %rcx,(%rdi) ; head = node->next\n151c917: movq $0x0,0x108(%r14) ; node->next = null\n151c922: mov 0xd0(%r14),%rcx\n151c929: addq $0x1,0x18(%rcx) ; bump refcount on context+0x18\n151c92e: addq $0x1,0x2240(%rcx) ; bump refcount on context+0x2240\n\n\nThe crashing function has two code paths reached from a test %r14,%r14; jne\nat 0x151c83e. The "remove" path was entered with r14 = NULL, so the\ndereference at +0x108 (the next field of the embedded list node) faults.\n\nThe crashing thread is io (LWP 1572855). The other ghostty-internal thread\n(LWP 1572854) was idle in epoll_wait. Main thread was in\ng_main_context_iteration. So this happens during queued-event processing\non ghostty's IO thread, ~9 s into startup.\n\n## Observations\n\n- Same offset on at least 6 separate crashes between Aug 19 and Aug 23, 2026\n on the same machine and binary. The bug is deterministic.\n- pacman.log shows ghostty installed on 2026-08-19; the binary's mtime is\n upstream's build (2026-04-10). No updates correlate with the crash.\n- Memory is healthy (~10/15 Gi used, ~3.8/30 Gi swap, no OOM events in\n journalctl --since 2026-08-19).\n- Arch's debuginfod has no debug info for ghostty (404), so I cannot map the\n offset to a function name. The disassembly above is from objdump.\n\n## Workarounds tried / proposed\n\nNone confirmed yet. Suspected (not yet verified by me) — same family of\nupstream-reported issues around fontconfig/init on the IO thread (#10432,\n#12968):\n- clearing ~/.cache/ghostty\n- launching without custom font-family / theme\n- downgrading to 1.2.x\n\nIf anyone can share a debug build of 1.3.1 for BuildID\n36aeb61c844ddf428f960758acdb8b37f30d7e31, I can produce a symbolized\nbacktrace.\n\n---\n\nFiled by MiniMax-M3 via opencode on behalf of user tang (omarchy).\n"

[pluiedev]

I figure we asked for a human summary of the issue not whatever this slop dump is, though outputting this as a double quote escaped string is certainly hilarious. Please do not interact in this discussion board again.

[pluiedev]

!denounce