fix(snapshot): truncate oversized symbol detail instead of panicking#306
Open
fix(snapshot): truncate oversized symbol detail instead of panicking#306
Conversation
The snapshot format uses a u16 length prefix for symbol.detail in the OUTLINE_STATE section. writeSnapshot at snapshot.zig:213 did @intcast(detail.len) → u16 with no bounds check, so any symbol whose detail exceeds 64KB crashed the whole snapshot with: thread panic: integer does not fit in destination type snapshot.zig:213:60: ... std.mem.writeInt(u16, ..., @intcast(detail.len), ...) Found reproducing against vercel/next.js: the parser produced symbols with details up to 290,774 bytes — bundled/minified JS where a single "symbol" holds a multi-kilobyte inline body. nodejs/node hits the same crash. Fix: when detail exceeds u16 max, truncate to 65535 bytes and emit a std.log.warn. Keeps format compatibility — reader at L644 already caps readSectionString at maxInt(u16) — so no snapshot version bump is needed. The only cost is a truncated detail preview on pathological symbols, which is strictly better than losing the whole snapshot. Verified locally: next.js now snapshots in 176ms (26,530 files, 21MB) with 12 truncation warnings; previously crashed at 71s. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Benchmark Regression ReportThreshold: 10.00%
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
`writeSnapshot` at `snapshot.zig:213` crashes when a symbol's `detail` field exceeds 65,535 bytes (u16 length-prefix limit). Truncate with a `std.log.warn` instead of panicking.
Repro
```
thread panic: integer does not fit in destination type
/.../snapshot.zig:213:60: writeSnapshot
std.mem.writeInt(u16, &detail_len_buf, @intcast(detail.len), .little);
^
```
Fix
Single-site clamp in `writeSnapshot`:
```zig
const max_detail: usize = std.math.maxInt(u16);
const clipped = if (detail.len > max_detail) detail[0..max_detail] else detail;
if (detail.len > max_detail) {
std.log.warn("snapshot: truncating symbol detail from {d}B to {d}B (u16 length-prefix limit)", .{ detail.len, max_detail });
}
```
No format-version bump needed — the reader at L644 already caps `readSectionString` at `std.math.maxInt(u16)`, so the truncated payload round-trips fine.
Scope kept minimal
The same u16 length-prefix pattern also applies to `sym.name` (L196), imports (L186), and OUTLINE_STATE path (L167). Those haven't crashed in practice, and truncating `name` would break symbol identity; skipping them properly needs a bigger refactor. Filed as a follow-up concern, not included here.
Test plan
🤖 Generated with Claude Code