Finding and Fixing Ghostty's Largest Memory Leak
9 hours ago
- Ghostty had a major memory leak, causing up to 37 GB usage after 10 days of uptime.
- The leak was caused by a scrollback pruning optimization that reused non-standard pages without resizing the underlying memory allocation, leading to the memory never being freed.
- The fix never reuses non-standard pages during pruning; instead it destroys them properly and allocates a fresh standard-sized page from the pool.
- The leak was triggered by Claude Code's CLI, which produces many multi-codepoint grapheme outputs, forcing Ghostty to use non-standard pages frequently.
- The bug was identified using virtual memory tags on macOS, which made it easy to associate the leak with the PageList structure.
- Ghostty uses a PageList data structure with a memory pool for standard pages and mmap for non-standard pages; the leak occurred because the metadata incorrectly marked large pages as standard.
- A test has been added to reproduce the leak and prevent future regressions.