smithery.ai

ghostty-crash

Debugging a ghostty crash

First seen Apr 5, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,061 B
  • docs SUMMARY.md 46 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

List dumps with ghostty +crash-report.

Crash dumps live in ~/.local/state/ghostty/crash/.

Crash file format

A .ghosttycrash file has two parts:

  1. JSON header - Sentry event data with build info, OS version, session duration
  2. Minidump - Binary starting with MDMP magic

Read JSON metadata (everything before MDMP). The header contains multiple JSON lines; the last line is the main Sentry event:

OFFSET=$(LC_ALL=C grep -ob 'MDMP' <crashfile> | head -1 | cut -d: -f1)
head -c $OFFSET <crashfile> | tail -1 | python3 -c "import sys,json; print(json.dumps(json.load(sys.stdin), indent=2))"

Extract the minidump:

tail -c +`LC_ALL=C grep -ob 'MDMP' <crashfile> | head -1 | cut -d: -f1 | xargs -I{} expr {} + 1` <crashfile> > /tmp/crash.dmp

Analysis

Analyze with minidump-stackwalk (install via cargo install minidump-stackwalk):

minidump-stackwalk /tmp/crash.dmp

Symbolicate addresses with atos. Get base address from minidump output (look for "ghostty" module):

atos -o /Applications/Ghostty.app/Contents/MacOS/ghostty -l <base_addr> <crash_addr>

Key context

Threads: Thread 0 is main/UI. Renderer runs on its own thread. Terminal I/O (termio) uses worker threads for processing input and running child processes.

Key source paths (in ghostty repo):

  • src/terminal/ - terminal emulation, pages, reflow
  • src/renderer/ - Metal/OpenGL rendering
  • src/termio/ - PTY and input handling
  • macos/Sources/ - Swift UI layer

Crash patterns:

  • EXCBADACCESS with address like 0xffffffff???????? usually indicates corrupted pointer arithmetic (e.g., bad offset added to valid base)
  • EXC_BREAKPOINT in Swift code indicates runtime assertion failure
  • Check if multiple crashes share register patterns (e.g., same suspicious capacity value) to identify related bugs

When comparing crashes: Look at uptime (session duration in JSON), thread ID, and register values. Same crash in same function with different addresses but similar register patterns suggests same root cause.

Exploring the codebase

Ghostty is written in Zig with platform-specific layers (Swift for macOS, GTK for Linux).

Build and test:

zig build              # debug build
zig build -Doptimize=ReleaseFast  # release build
zig build test         # run tests
zig build test -Dtest-filter="PageList"  # filter tests by name

Threading model: Terminal state is protected by rendererstate.mutex (defined in src/renderer/State.zig). The renderer locks it during frame updates; termio locks it during resize and input processing. Look for rendererstate.mutex.lock() to trace critical sections.

Finding callers: Use grep for function names. Zig uses foo.bar() method syntax but defines as fn bar(self: *Foo), so search for both the method name and struct type.

Report

Record findings in CRASH.md, including the dump filename and the commands required to reproduce the analysis.