Memory leak persists on tip build 1.3.0-main+17da13840 after PageList fix

[kevincorvallis]

Issue Description

Summary

After updating to the tip build that includes the PageList memory leak fix (PR #10251), I'm still experiencing runaway memory growth with the same VM_ALLOCATE pattern. Fresh process started after updating, using Claude Code.

Environment

Ghostty 1.3.0-main+17da13840
Version
  - version: 1.3.0-main+17da13840
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS: macOS 26.2 (25C56)
Architecture: ARM64

Confirming Fresh Process on Tip Build

$ ps -o pid,lstart,comm -p 2827
  PID STARTED                      COMM
 2827 Sat Jan 10 19:11:43 2026     /Applications/Ghostty.app/Contents/MacOS/ghostty

$ ls -la /Applications/Ghostty.app/Contents/MacOS/ghostty
.rwxr-xr-x@ 41M kevin 10 Jan 08:11 /Applications/Ghostty.app/Contents/MacOS/ghostty

Binary was updated at 08:11, process started at 19:11 — confirming this is a fresh process running the tip build, not a carryover from the previous install.

Reproduction

Fresh Ghostty process started after updating to tip (PID 2827, launched Jan 10 at 7:11 PM)

Heavy Claude Code usage over ~9.5 hours

Memory grew to 154GB

Diagnostics

vmmap summary

Physical footprint:         154.7G
Physical footprint (peak):  154.7G

Writable regions: Total=155.1G written=332.0M(0%) resident=3.9G(3%) swapped_out=150.6G(97%) unallocated=656.0M(0%)

VM_ALLOCATE                 154.0G     3.4G     3.4G   150.6G       0K       0K       0K   272399

272,399 VM_ALLOCATE regions totaling 154GB.

Region size analysis

vmmap 2827 | grep "VM_ALLOCATE" | awk -F'[][]' '{print $2}' | sort | uniq -c | sort -rn | head -20

254742   592K     0K     0K   592K
  8090   608K     0K     0K   608K
  3417   592K   592K   592K     0K
   837   672K     0K     0K   672K
   735   592K   576K   576K    16K
   555   592K   416K   416K   176K
   443   592K    16K    16K   576K
   280   592K   432K   432K   160K
   ...

Key finding: 254,742 regions are exactly 592K and fully swapped out. The uniform size suggests a single allocation pattern is leaking.

Sample regions

VM_ALLOCATE                 311e20000-311eb4000    [  592K     0K     0K   592K] rw-/rwx SM=COW  
VM_ALLOCATE                 34b814000-34b8a8000    [  592K     0K     0K   592K] rw-/rwx SM=COW  
VM_ALLOCATE                 34ba68000-34bafc000    [  592K     0K     0K   592K] rw-/rwx SM=COW

Regions show as generic VM_ALLOCATE — I don't see the application_specific_1 tag that was added in the fix. Not sure if that's expected in vmmap output or not.

Observations

• This is a fresh process started after updating to tip — not a carryover from an old build
• The leak pattern (hundreds of thousands of uniform VM_ALLOCATE regions) matches the original PageList leak reports
• 592K is close to what I'd expect a "standard page" size might be
• Claude Code was the primary workload, same as the original trigger

Questions

1. Is 592K the standard page size? If so, could standard pages be leaking under some condition the fix didn't cover?
2. Should I expect to see VM tags in vmmap output, or do they only show in Instruments?
3. Is there additional diagnostic info I can capture?

Expected Behavior

Memory usage should remain stable during extended usage sessions. With the PageList memory leak fix (PR #10251), VM_ALLOCATE regions should not accumulate indefinitely.

Actual Behavior

Memory grows to 154GB over ~9.5 hours of heavy usage. 272,399 VM_ALLOCATE regions accumulate, with 254,742 of them being exactly 592K in size and fully swapped out. This matches the pattern from the original PageList leak reports.

Reproduction Steps

1. Update to tip build 1.3.0-main+17da13840 (includes PageList fix from PR Fix memory leak when pruning scrollback with non-standard pages #10251)
2. Start fresh Ghostty process
3. Use Claude Code heavily for extended session (~9.5 hours)
4. Monitor memory with vmmap <PID>
5. Observe runaway memory growth with accumulating VM_ALLOCATE regions

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+17da13840

Version
  - version: 1.3.0-main+17da13840
  - channel: tip

Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.2 (25C56) - ARM64

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

theme = "Gitlab Dark"
font-family = "JetBrainsMono Nerd Font Mono"
font-size = 14
bold-is-bright = true
cursor-style = block
cursor-style-blink = false
window-padding-x = 10
window-padding-y = 10
background-opacity = 0.95
background-blur = 12
window-vsync = true
scrollback-limit = 20000
mouse-scroll-multiplier = 1.0
shell-integration = detect
macos-titlebar-style = tabs
macos-option-as-alt = true
window-save-state = never
confirm-close-surface = true
keybind = cmd+shift+c=copy_to_clipboard
keybind = cmd+shift+v=paste_from_clipboard
keybind = cmd+shift+k=clear_screen

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[kevincorvallis]

Update: Root cause identified and PR submitted

I've identified the root cause of this leak and submitted a fix: #10270

The Issue

PR #10251 fixed non-standard page leaks during scrollback pruning, but a similar leak existed in the adjustCapacity() code path. When a standard-sized page (592K) is expanded to non-standard size during adjustCapacity(), the old standard page was being returned to the memory pool via pool.pages.destroy(). However, since the pool uses an ArenaAllocator that never frees individual items, these pages accumulated indefinitely.

This is particularly common with emoji-heavy and hyperlink-rich output (like Claude Code), where adjustCapacity() is frequently called to expand page capacity for graphemes, hyperlinks, or styles.

The Fix

The fix follows the same pattern as PR #10251: when replacing a standard page with a non-standard page during adjustCapacity(), munmap the old page directly instead of returning it to the pool.

This should resolve the 254,742 leaked 592K regions observed after 9.5 hours of usage.

[mitchellh]

There's a shitload of slop in here. I'm going to close this and request you do some more analysis and reopen a discussion with more details. It would help to see footprint results (That'll show VM tags) and to try to narrow down how you triggered this more. There is one known memory leak #10258 this might be too, so read that and compare and note the differences there (i.e. does the memory free with window close? if so, its a different leak). Use your brain a bit and report back, or we'll wait for other reports. Thank you!