Linux/GTK 1.3.1: repeatable SIGSEGV in io thread — null+0x108 deref, single-instance startup path

[gotar]

Ghostty 1.3.1 (Arch 1.3.1-2, now upgraded to Omarchy rebuild 1.3.1-3 / 1.3.1+omarchy.3) segfaults repeatedly in the thread named io.

Two dumps 6s apart share a byte-identical signature:

• PID 1371: /usr/bin/ghostty, SIGSEGV SEGV_MAPERR, ghostty+0x151c90d, fault 0x108, error 4
• PID 8859: /usr/bin/ghostty --gtk-single-instance=true --working-directory=/home/gotar, same offset, same fault, died ~1s after startup
• coredumpctl history shows the same program SIGSEGV-ing Jul 8, Sep 16, Sep 29, Oct 4, Oct 8 (x2), Oct 12, Oct 15 (x2)
• Registers (both): r14==0, rax==0, faulting insn mov 0x108(%r14),%rcx; preceding: cmp 0x8(%rdi),%r14 / jne crash / movq $0,0x8(%rdi)
• Stack: single frame in ghostty, return address zero. Unsymbolized — Arch debuginfod + ghostty-debug 1.3.1-3 installed, but the available cores are from build 1.3.1-2 so they don't resolve. No third-party code in the address space (system libs + Mesa amdgpu only).
• Ruled out: OOM (19G avail, 84M peak, no OOM kills), recent update (ghostty last built April, crashes predate it).
• Nearby open issue 14245 is the same thread family but a deadlock, not this SEGV; no open/closed issue matches this signature that I could find.

Happy to capture a fresh 1.3.1-3 core with debug symbols if it recurs — it hasn't since the rebuild. Is this a known surface-teardown race on the GTK single-instance path?

Filed by Muse Spark via pi.