bug: PageList.resizeCols panics on unreachable reflowing hyperlinks — string_bytes precondition invalidated by increaseCapacity(.hyperlink_bytes)

[Korel]

Disclosure: this investigation, analysis and write-up were produced by an AI agent (Claude), driven by a human who hit the crash and reviewed the result before posting. All evidence below is from real crash artifacts on a real machine, not synthesised. Paths, hostnames and session/project names have been redacted.

Summary

PageList.resizeCols can panic on unreachable while reflowing rows that contain OSC 8 hyperlinks. The string_bytes capacity precondition established at PageList.zig:1922-1941 is invalidated by the increaseCapacity(list, .hyperlink_bytes) call at line 1972, because that call swaps self.page for a new page. The subsequent src_link.dupe at line 1978 can then legitimately return error.OutOfMemory, which the code treats as impossible.

This only aborts in safety-on builds. Ghostty's own app ships .ReleaseFast, where the if (comptime std.debug.runtime_safety) block is comptime-eliminated and control falls through to break :hyperlink, silently dropping one hyperlink. So this is effectively invisible in Ghostty itself, but it is a hard process abort for libghostty-vt consumers that build ReleaseSafe/Debug.

I found it via zmx, which embeds ghostty-vt and builds it .ReleaseSafe. There it kills the session-owning daemon and destroys the user's terminal session. Filing separately against zmx for the build-mode/isolation side; this report is only about the upstream defect.

The defect

In ReflowCursor.writeCell (src/terminal/PageList.zig, function starts line 1728), current main:

// 1909: hyperlink capacity is topped up FIRST — fine.
if (self.page.hyperlinkCount() >= self.page.hyperlinkCapacity()) {
    try self.increaseCapacity(list, .hyperlink_bytes);
}

// 1922-1941: establish the string_bytes precondition against *this* self.page
while (true) {
    if (self.page.string_alloc.alloc(u8, self.page.memory,
                                     additional_required_string_capacity)) |slice| {
        self.page.string_alloc.free(self.page.memory, slice);
        break;
    } else |_| {
        try self.increaseCapacity(list, .string_bytes);
    }
}

const dst_link = src_link.dupe(src_page, self.page) catch |err| { ... };   // 1943 — precondition valid

const dst_id = self.page.hyperlink_set.addWithIdContext(...) catch |err| id: {
    dst_link.free(self.page);

    try self.increaseCapacity(list, switch (err) {                          // 1972  <-- invalidates it
        error.OutOfMemory => .hyperlink_bytes,
        error.NeedsRehash => null,
    });

    const dst_link2 = src_link.dupe(src_page, self.page) catch |err2| {     // 1978
        // This shouldn't fail since we did a capacity
        // check above.
        log.err("link dupe failed with capacity check err={}", .{err2});
        if (comptime std.debug.runtime_safety) {
            unreachable;                                                     // 1987  <-- panic
        }
        break :hyperlink;
    };

The comment at 1982-1983 is the bug: the capacity check "above" was performed against a page that no longer exists at line 1978.

ReflowCursor.increaseCapacity (line ~2177) rebinds the cursor to a brand-new node:

const node = ... try list.increaseCapacity(self.node, adjustment);
errdefer comptime unreachable;
self.* = .init(node);
self.cursorAbsolute(old_x, old_y);
self.total_rows = old_total_rows;

So after the .hyperlink_bytes bump at 1972, self.page is a different page. Its string_bytes capacity is not re-derived from additional_required_string_capacity, and the string arena in the new page has already been consumed by the URIs copied into it so far during this reflow. dupe then fails on string_alloc, not on hyperlink capacity — which is exactly why bumping .hyperlink_bytes doesn't help.

The same stale-precondition shape exists at the third site (line ~2002, addWithIdContext after the capacity increase), though that is not the one that fired here.

Evidence

Two independent aborts, ~3h45m apart, byte-identical stacks. Symbolicated frames from the macOS crash reports (addresses, UUIDs and paths stripped):

libsystem_kernel.dylib   __pthread_kill
libsystem_pthread.dylib  pthread_kill
libsystem_c.dylib        abort
zmx                      posix.abort
zmx                      debug.defaultPanic
zmx                      debug.FullPanic(...).reachedUnreachable
zmx                      terminal.PageList.resizeCols          <-- writeCell inlined
zmx                      terminal.PageList.resize
zmx                      terminal.Terminal.resize
zmx                      main.daemonLoop
...

EXC_CRASH / SIGABRT, macOS 26.5.2, arm64.

The page_list scope log lines immediately preceding each abort, at the same millisecond as the recorded crash time (timestamps and session name removed):

Crash 1 — column count 319 -> 159:

[info]  (page_list): adjusting page capacity=.{ .cols = 159, .rows = 299, .styles = 128, .hyperlink_bytes = 384,  .grapheme_bytes = 8192, .string_bytes = 2048 }
[info]  (page_list): adjusting page capacity=.{ .cols = 159, .rows = 299, .styles = 128, .hyperlink_bytes = 768,  .grapheme_bytes = 8192, .string_bytes = 2048 }
[info]  (page_list): adjusting page capacity=.{ .cols = 159, .rows = 299, .styles = 128, .hyperlink_bytes = 1536, .grapheme_bytes = 8192, .string_bytes = 2048 }
[error] (page_list): link dupe failed with capacity check err=error.OutOfMemory
<abort>

Crash 2 — column count 239 -> 119:

[info]  (page_list): adjusting page capacity=.{ .cols = 119, .rows = 413, .styles = 128, .hyperlink_bytes = 1536, .grapheme_bytes = 8192, .string_bytes = 2048 }
[error] (page_list): link dupe failed with capacity check err=error.OutOfMemory
<abort>

Note the signature in crash 1: hyperlink_bytes doubling 384 -> 768 -> 1536 while string_bytes stays pinned at 2048. That is the retry at line 1972 escalating the wrong dimension, then line 1978 failing on the dimension nobody re-checked.

Both crashes are a halving of the column count (319→159, 239→119), i.e. a vertical pane split / window halving, which forces a full-scrollback reflow.

Affected version

The crashing binary embeds ghostty-vt pinned at 30e1f3bb8c3d2949e9ae4aefc1c2b76142569cfb (2026-07-21), hash ghostty-1.3.2-dev-5UdBC5gHIgWG-_Voonf5F76Vt2I2KljI5lIuvI-7eyBI.

I diffed the whole of resizeCols between that commit and current main: byte-identical. The writeCell hyperlink block quoted above is likewise unchanged. So main is still affected.

For the avoidance of doubt, this is not a regression of #12907 / #12935 (5a1edfb, "guard wrap count when resize pushes cursor to scrollback"). That fix is present — the pin is 306 commits ahead of it and 0 behind — and both guards it added are in the code. This is a distinct second panic inside the same function.

Reproduction

I do not have a minimal repro, and I want to be upfront about that rather than pad the report.

I drove ~700 scripted TIOCSWINSZ resizes (including repeated exact halvings) against scrollback filled with hundreds of unique OSC 8 links with long URIs and long explicit id= values, plus SGR styling, and could not trip it. Reaching line 1978's failure needs a specific simultaneous near-exhaustion of the hyperlink set and the string arena within a single page at the moment of reflow, which I could not steer synthetically.

The static argument above stands on its own, though: line 1972 provably rebinds self.page, and the precondition guarding line 1978 was established against the previous page. The two production aborts with the matching hyperlink_bytes escalation signature confirm the path is live.

Suggested fix

Re-establish the precondition after the capacity change rather than assuming it survived — e.g. hoist the 1922-1941 loop into a small helper and call it again after the increaseCapacity at 1972, before re-duping. That also makes the third site (~2002) safe.

Failing that, the two unreachables could be demoted to the already-written break :hyperlink fallback, since dropping a hyperlink is a correct and non-fatal degradation — but that hides a real capacity-management bug, so re-checking is preferable.

Happy to open a PR if you'd like it fixed this way.

[mitchellh]

Fixed here: #13524

Thank you