Conversation
Picks up wasmerio/napi#57, which makes the QuickJS backend report a real heap_size_limit instead of 0. This unblocks the quickjs-wasix lane. scripts/test-wasix-safe-mode.py gained a "v8 heap statistics report the embedder limit" case on 2026-08-05 (b7b3c14), the same day the dgram regression started aborting that job at the earlier test-suite step. The smoke-test step has never run to completion on the QuickJS lane since, so the check has never passed there; skipping the dgram test in the parent commit is what first let CI reach it, and it failed with expected: 'HEAP true\n' actual: 'HEAP false\n' The V8 backend was always fine, which is why v8-wasix stayed green. With the bump the whole safe-mode suite passes locally against the quickjs-wasix build.
child_process.exec() and execSync() do not spawn the command directly -- they run it through `/bin/sh -c`. The root package ships no shell, so every exec() in the V8 WASIX package failed to spawn one. The QuickJS package has declared this dependency since it was created; this one never did. Surfaced by test-http-chunk-problem and test-http-full-response on the v8-wasix lane, which #115 stops skipping. Both exec an external tool and both are written to cope with it being absent, but they never got the chance: with no shell to resolve, the spawn failed before their callback ran. They pass on quickjs-wasix, which has the shell. The uncaught throw those tests hit is a second, separate bug -- proc_spawn reported ENOEXEC rather than ENOENT for an unresolvable command, and Node only converts a known errno set into an 'error' event (wasmerio/wasmer#6877). Either fix alone makes these two tests pass; both are worth having, since this one also makes exec() work at all.
Member
|
This PR is no longer necessary, We can close this |
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.
Stacked on #144. Merge bottom-up: #143 → #144 → this → #115.
Picks up wasmerio/napi#57 (stacked on napi#54, which #143 already pins).
Why this is needed
#144 fixes the dgram timeout, and
v8-wasixgoes green — butquickjs-wasixthen fails at a later step it had never previously reached:This is not a regression from #144. The check was added to
scripts/test-wasix-safe-mode.pyon 2026-08-05 (b7b3c149) — the same day the dgram regression began aborting that job at the earlier test-suite step. Since then the smoke-test step has never run to completion on the QuickJS lane, so the check has never passed there. Skipping the dgram test is simply what let CI get far enough to see it.Confirmed against the last green run (30567886962, 2026-07-30): the case did not exist yet, and the smoke-test step passed.
Root cause
unofficial_napi_get_heap_statistics()in the QuickJS backend memsets the struct and fills only the size fields, leavingheap_size_limitat 0. The V8 backend sets it fromstats.heap_size_limit(), which is whyv8-wasixwas unaffected.It can't be forwarded directly either: QuickJS spells "no limit" as
malloc_limit == 0, the inverse of the N-API convention. napi#57 translates between them — a configured limit is reported as-is, an unset one reports the address-space ceiling (on wasm32,SIZE_MAX= 4 GiB − 1, exactly the linear-memory ceiling).Per the check's own comment this is a real bug, not just a test artifact: Next.js reads the value to decide whether a worker is near its heap limit, and a zero makes its memory watchdog exit eagerly.
Verification
Rebuilt the quickjs-wasix guest with the bump; the full safe-mode suite passes:
Values now reported under WASIX: