os/open: stderr reader thread spins at 100% CPU forever once the opener writes a newline (takeDelimiterExclusive never consumes the delimiter)

[jzillmann]

Summary

openThread in src/os/open.zig reads the spawned opener's stderr with takeDelimiterExclusive('\n'). In Zig 0.16, that function never consumes the delimiter, so after the child writes a single newline to stderr, every subsequent call returns an empty slice without advancing the stream. The loop then spins forever: one fully pinned CPU core per affected open, logging os-open: open stderr= (empty payload) at tens of thousands of messages per second, for the lifetime of the process. The thread also never reaches exe.wait(), so the child is never reaped.

Present in current main (8168115): https://github.com/ghostty-org/ghostty/blob/8168115/src/os/open.zig#L79-L101

Mechanics

Zig 0.16 std/Io/Reader.zig:

pub fn takeDelimiterExclusive(r: *Reader, delimiter: u8) DelimiterError![]u8 {
    const result = try r.peekDelimiterExclusive(delimiter); // strips the trailing '\n' from the slice
    r.toss(result.len);                                     // tosses only the EXCLUSIVE length
    return result;
}

So for buffered stderr "some warning\n":

1. First call returns "some warning" and tosses 12 bytes — the '\n' stays buffered.
2. Next call: peekDelimiterInclusive finds '\n' at position 0 → inclusive slice "\n" → exclusive slice "" → toss(0).
3. Nothing is ever consumed again. The while (true) loop in openThread receives "" forever — no EndOfStream, no ReadFailed — and logs an empty warning each iteration.

Observed impact

macOS app embedding libghostty, several days of uptime: six leaked opener threads (six link clicks whose /usr/bin/open wrote something to stderr), each pinned at ~70% of a core, ≈4.4 cores total. Unified log flooded with ~27k messages/second of:

E  [com.mitchellh.ghostty:default] os-open: open stderr=

sample shows all six threads inside the openThread loop, dominated by os_log → voucher_activity_trace_v_2 → _dlock_wait (firehose lock contention from the log spam).

Reproduction

Any platform where the opener writes at least one newline to stderr. On macOS:

# make /usr/bin/open complain to stderr, e.g. click an OSC 8 link with a scheme
# that has no handler; or observe directly:
open x-nonexistent-scheme://foo   # writes an error line to stderr

Then watch one CPU core disappear and log stream --predicate 'subsystem == "com.mitchellh.ghostty"' fill with empty os-open: open stderr= lines.

Suggested fix

Consume the delimiter — e.g. read inclusively and trim for logging:

while (true) {
    const line = reader.takeDelimiterInclusive('\n') catch |outer| switch (outer) {
        error.EndOfStream => break,
        error.ReadFailed => break,
        error.StreamTooLong => reader.take(buffer.len) catch |inner| switch (inner) {
            error.ReadFailed => break,
            error.EndOfStream => break,
        },
    };
    log.warn("open stderr={s}", .{std.mem.trimEnd(u8, line, "\n")});
}

(takeDelimiter works too; anything that advances past the '\n'.)

[jcollie]

!vouch

[mjbommar]

fyi i think these two were interrelated when i first reported:
#13267

hit that combo bug again in 1.3.2 today. was the OSC issue addressed separately?