Skip to content

Size asyncify buffer from max stack size so deep suspensions cannot abort (part of #274) - #282

Open
jackkav wants to merge 10 commits into
justjake:mainfrom
jackkav:fix-asyncify-stack
Open

jackkav wants to merge 10 commits into
justjake:mainfrom
jackkav:fix-asyncify-stack

Conversation

@jackkav

@jackkav jackkav commented Oct 16, 2026 •

Copy link
Copy Markdown

Layer: C interface (c/interface.c, Asyncify.StackSize set at runtime) + docs. No build-flag change
Review just this PR: jackkav/quickjs-emscripten@fix-bjson-references...fix-asyncify-stack
Stack: #248 → #276 → #277 → (#278 | #279 → #280 → #281 → #282). Issues: #274, #275.

What

  • Suspending in deep recursion aborted the module (unreachable): the asyncify buffer was sized to exactly the QuickJS stack limit but needs 1.0–1.9x more (measured over 6 recursion shapes, release/debug, both engines). setMaxStackSize now sizes it to 3x the limit (≥ build default, ≤ 1 GiB), so QuickJS throws its catchable stack overflow first.
  • Not changed: with no setMaxStackSize call the default stays 81920 and a ~300-deep suspension can still abort. Fixing the default costs 768 KiB (quickjs) to 3 MiB (quickjs-ng) of transient heap per suspended call; that is your call, happy to add it.

Test: 3 recursion shapes (plain at two limits): find the deepest recursion QuickJS allows, suspend there, expect completion. All fail on wasm built from main (the abort also poisons later tests in the module). Array#map/apply shapes only run at the smaller limit to stay under node's own call stack.
Verified on: Full suite on freshly built wasm for every variant in the test matrix (sync/async × release/debug × quickjs/quickjs-ng) at the top of the stack (#282): 751 passed, 0 failed. Debug builds run the leak sanitizer check in afterAll.
Behavior change: With an explicit setMaxStackSize(n), each suspended async call transiently allocates 3n bytes (was n).
Overlap: Touches QTS_RuntimeSetMaxStackSize; no overlap with #207 beyond possible textual conflicts in c/interface.c.

🤖 Generated with Claude Code

justjake and others added 10 commits October 15, 2026 20:35
When Emscripten's WASM memory grows (due to -sALLOW_MEMORY_GROWTH), all
existing TypedArray views become detached because the underlying
ArrayBuffer is replaced. This caused bugs where reading from views after
FFI calls returned undefined values if memory had grown.

The fix introduces RefreshableTypedArray, a wrapper that lazily recreates
the TypedArray view when HEAPU8.buffer changes. This is a simple reference
comparison that only triggers view recreation when actually needed.

Affected call sites:
- runtime.ts: executePendingJobs - reads ctxPtrOut after QTS_ExecutePendingJob
- context.ts: newPromise - reads resolve/reject handles after QTS_NewPromiseCapability
- context.ts: getLength - reads uint32Out after QTS_GetLength
- context.ts: getOwnPropertyNames - reads outPtr and uint32Out after QTS_GetOwnPropertyNames

Also fixed: getOwnPropertyNames was using HEAP8.buffer instead of HEAPU8.buffer

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- getArrayBuffer returned a HEAPU8.subarray view that is detached by the next
  WASM memory growth; return a copy instead.
- consumeJSCharPointer / consumeHeapCharPointer leaked the C string when
  UTF8ToString threw (e.g. strings longer than V8's max string length).
- newArrayBuffer leaked the host buffer (and returned an exception-tagged
  handle) when QuickJS failed to create the ArrayBuffer. It now frees the
  buffer and throws.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…reelist

- ModuleMemory helpers now throw on a null _malloc instead of writing at address 0.
- getOwnPropertyNames freed a plain-malloc'd array with js_free (QTS_FreeVoidPointer),
  unbalancing QuickJS allocation counters; free it with the module's free.
- HostRefMap: FIFO freelist used Array#shift (quadratic when draining); use a head index.
  Deleting an already-deleted id in a non-empty group no longer queues it for reuse twice.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…y arguments

- QTS_RuntimeDumpMemoryUsage wrote into a fixed 1 KiB fmemopen buffer, truncating the
  report mid-line once more than a few object kinds exist. Use open_memstream.
- QTS_Call built a variable-length array of argc values on the wasm shadow stack; a
  few hundred thousand arguments trapped the whole module. Heap allocate instead, and
  throw out-of-memory if that fails.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…wnPropertyNames

- newContext (sync and asyncify) wrapped a NULL context pointer and carried on; throw.
- ContextMemory.heapValueHandle wrapped the NULL returned by jsvalue_to_heap when it
  cannot malloc; throw.
- QTS_GetOwnPropertyNames did not check its output malloc, and sized it per JSValue
  (8 bytes) instead of per JSValue* (4 bytes); check it, free the property atoms and
  throw out-of-memory on failure.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
QTS_bjson_encode writes with JS_WRITE_OBJ_REFERENCE so shared and cyclic objects
encode, but QTS_bjson_decode read with flags 0, so decoding them failed with
"object references are not allowed". Pass JS_READ_OBJ_REFERENCE. Bytecode and
SharedArrayBuffer remain disallowed.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…cannot abort

Asyncify's buffer holds the saved locals of each suspended wasm frame, which needs up to
~1.9x the native stack depth that JS_SetMaxStackSize limits (measured across release/debug,
quickjs/quickjs-ng and several recursion shapes). With the buffer set to exactly the limit,
suspending near the deepest recursion QuickJS allows overflowed it and aborted the module
("unreachable"). Set it to 3x the limit (at least the build default), capped at 1 GiB.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants