fix: zero-initialize WASM page buffers to prevent memory corruption#142
Open
sauyon wants to merge 2 commits into
Open
fix: zero-initialize WASM page buffers to prevent memory corruption#142sauyon wants to merge 2 commits into
sauyon wants to merge 2 commits into
Conversation
…#141) PageList only zeroed page buffers in debug/safe builds, relying on the OS to guarantee zeroed memory in release builds. On WASM there is no OS guarantee — the allocator reuses freed memory as-is. This caused two bugs: 1. Stale cell data from freed terminals appearing in newly created ones 2. WASM memory corruption after freeing terminals that processed multi-codepoint grapheme clusters (flag emoji, skin tones, ZWJ sequences), crashing all subsequent terminal writes The fix makes @Memset(page_buf, 0) unconditional on WASM in both initPages and createPageExt. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
4 tasks
diegosouzapw
added a commit
to diegosouzapw/ghostty-web
that referenced
this pull request
May 23, 2026
…tion Ghostty allocates page buffers via the wasm allocator (which calls wasm_alloc -> memory.grow). New memory pages on grow are zero on most runtimes but the cell layout depends on this being EXPLICITLY true: some cell fields are inspected before the first write, and a stray non-zero byte can corrupt the screen state in ways that surface much later (wrong colors, stuck cursor, dropped grapheme clusters). Patches/ghostty-wasm-api.patch is updated so the underlying buffer arrays are explicitly memset-to-zero at construction. Adds two TS-side regression tests that exercise the corrupted-render shape. Co-authored-by: Sauyon Lee <git@sjle.co> Inspired-by: coder#142
diegosouzapw
added a commit
to diegosouzapw/ghostty-web
that referenced
this pull request
May 23, 2026
…tion (#12) Ghostty allocates page buffers via the wasm allocator (which calls wasm_alloc -> memory.grow). New memory pages on grow are zero on most runtimes but the cell layout depends on this being EXPLICITLY true: some cell fields are inspected before the first write, and a stray non-zero byte can corrupt the screen state in ways that surface much later (wrong colors, stuck cursor, dropped grapheme clusters). Patches/ghostty-wasm-api.patch is updated so the underlying buffer arrays are explicitly memset-to-zero at construction. Adds two TS-side regression tests that exercise the corrupted-render shape. Inspired-by: coder#142 Co-authored-by: Sauyon Lee <git@sjle.co>
|
Hi @sauyon! 👋 Your work on this PR inspired a commit in my fork diegosouzapw/ghostty-web. I'm working on OmniRoute, a project that provides free access to LLM models, and I'm planning to use ghostty-web as the terminal component there. Your work is part of what makes that possible. 🙏 Feel free to check it out — contributions and feedback are very welcome! |
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
2 participants
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.
PageList only zeroed page buffers in debug/safe builds, relying on the OS to guarantee zeroed memory in release builds. On WASM there is no OS guarantee — the allocator reuses freed memory as-is. This caused two bugs:
The fix makes @Memset(page_buf, 0) unconditional on WASM in both initPages and createPageExt.
Includes two previously-failing regression tests. Should resolve #141.