Skip to content

Fix truncated dumpMemoryUsage and QTS_Call stack overflow with many args (part of #275) - #279

Open
jackkav wants to merge 7 commits into
justjake:mainfrom
jackkav:fix-c-dump-and-call-args
Open

jackkav wants to merge 7 commits into
justjake:mainfrom
jackkav:fix-c-dump-and-call-args

Conversation

@jackkav

@jackkav jackkav commented Oct 16, 2026 •

Copy link
Copy Markdown

Layer: C interface (c/interface.c)
Review just this PR: jackkav/quickjs-emscripten@fix-oom-and-hostref...fix-c-dump-and-call-args
Stack: #248 → #276 → #277 → (#278 | #279 → #280 → #281 → #282). Issues: #274, #275.

What

  • QTS_RuntimeDumpMemoryUsage used a fixed 1 KiB fmemopen buffer, cutting the report mid-line. Now open_memstream.
  • QTS_Call built a variable-length array of argc values on the wasm stack; ~700k+ args trapped the whole module. Now heap-allocated, with JS_ThrowOutOfMemory on failure.

Test: 2 new tests, both fail on wasm built from main (truncated report; memory access out of bounds) and pass with the change. The call-args test also checks the module still evaluates code afterwards.
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: callFunction with a huge argument list returns a catchable InternalError instead of killing the module.
Overlap: #207 also edits c/interface.c (memory-usage code); possible textual conflict near QTS_RuntimeDumpMemoryUsage, no conflicting intent.

🤖 Generated with Claude Code

justjake and others added 7 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>
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