list_empty(&rt->gc_obj_list) assertion on dispose after allocating many objects inside a promise job (minimal repro, no host functions)

[jackkav]

Allocating many objects inside a promise job leaves the runtime un-freeable: context.dispose() aborts the WASM module on assert(list_empty(&rt->gc_obj_list)) in JS_FreeRuntime. Notably the objects themselves have already been collected by then (see the memory numbers below), so this does not look like simple retention.

Probably the same root cause as #235, filed separately because this reproducer is minimal: no host functions, no Scope, no newPromise, no memory limit, no async host work. Just VM-side allocation in a job, then dispose.

Reproducer

import { newQuickJSWASMModuleFromVariant } from 'quickjs-emscripten-core'
import variant from '@jitl/quickjs-wasmfile-release-sync'

const QuickJS = await newQuickJSWASMModuleFromVariant(variant)
const vm = QuickJS.newContext()

// A plain promise job. No host function, no await, no bridge.
const r = vm.evalCode(
  `Promise.resolve().then(() => {` +
  `  const a = [];` +
  `  for (let i = 0; i < 200000; i++) { a.push({ i }); }` +
  `  globalThis.__k = a.length;` +
  `});`
)
if (r.error) { r.error.dispose() } else { r.value.dispose() }

vm.runtime.executePendingJobs().dispose()

const h = vm.getProp(vm.global, '__k')
console.log('__k =', vm.dump(h))   // 200000 — the script ran fine
h.dispose()

vm.dispose()                        // 💥 abort

Aborted(Assertion failed: list_empty(&rt->gc_obj_list), at: ../../vendor/quickjs/quickjs.c,2036,JS_FreeRuntime)

The same thing written with an async IIFE + await aborts identically, so it is not specific to async functions:

vm.evalCode(`(async()=>{await Promise.resolve();` +
  `const a=[];for(let i=0;i<200000;i++){a.push({i});}` +
  `globalThis.__k=a.length;})();`)

Affects both C engines

Reproduced at 0.32.0 on both, which suggests the glue/FFI layer rather than one engine:

variant	result
@jitl/quickjs-wasmfile-release-sync	Aborted(… list_empty(&rt->gc_obj_list), at: ../../vendor/quickjs/quickjs.c,2036,JS_FreeRuntime)
@jitl/quickjs-wasmfile-debug-sync	same
@jitl/quickjs-ng-wasmfile-release-sync	Aborted(… list_empty(&rt->gc_obj_list), at: ../../vendor/quickjs-ng/quickjs-amalgam.c,12520,JS_FreeRuntime)
@jitl/quickjs-ng-wasmfile-debug-sync	same

What narrows it

All at 200k iterations, each run in a fresh process:

case	result
job + retained array of objects	abort
job + retained array of objects, a = null before the job returns	abort
job + objects allocated but never retained	clean
job + retained array of numbers	clean
job + 200k-char string built by concatenation	clean
same allocation synchronously (no job), 200k and 300k	clean

So the trigger is many GC-tracked objects allocated during a promise job. Reachability at the end of the job is irrelevant — nulling the array still aborts.

Threshold on this machine is between 50k and 100k objects for a JSON.parse(JSON.stringify(...)) variant of the same script.

The objects are already gone when it aborts

runtime.computeMemoryUsage() immediately before the aborting dispose(), for the 200k-object .then reproducer above:

{
  "malloc_limit": 4294967295,
  "memory_used_size": 86426,
  "obj_count": 331,
  "prop_count": 1747,
  "array_count": 2
}

86KB used and 331 objects — the 200k objects have been collected, and there is no memory pressure. So whatever is left in gc_obj_list is small, and the allocation volume appears to matter only because it forces a GC cycle during the job rather than because anything is being retained. That is a hypothesis, not something I have confirmed at the C level — I have no build with -sASSERTIONS to dump the list contents.

Ruled out (host-side)

None of these change the outcome:

• Not calling runtime.setMemoryLimit() at all, or raising it to 512MB
• Not calling runtime.setInterruptHandler()
• Polling context.getPromiseState() instead of context.resolvePromise() (so no host newFunction callbacks are installed at all)
• Extra executePendingJobs() passes after the job completes
• runtime.computeMemoryUsage() before dispose (per the suggestion on Reproducible list_empty assertion failure #235)
• Forcing further allocation afterwards to provoke a GC

computeMemoryUsage() shows no memory pressure at all (numbers above), so this is not the near-OOM situation in #257.

Environment

• quickjs-emscripten / quickjs-emscripten-core / @jitl/* all 0.32.0 (current latest)
• Node v24.14.0, darwin arm64

Why it matters

We hit this in Insomnia, running user-authored pre-request scripts in QuickJS. Any script that does await someHostCall() and then parses a response body of a few MB crashes the whole worker — and because it is a native abort() rather than a thrown error, it cannot be caught and reported as a script failure. The abort escapes context.dispose() in a finally block, replacing whatever the real result or error was.

Happy to test patches or narrow this further.

[jackkav]

Follow-up: I tried to narrow this to a patch and got as far as "it is not quickjs's C logic — it is specific to the WASM build". Sharing the negative results so nobody repeats them, plus two build discrepancies that look worth a look.

The same C source is clean natively

I downloaded the exact vendored tree (vendor/quickjs, VERSION = 2025-09-13) and built a minimal native harness that mirrors the shim's call sequence — JS_NewRuntime → JS_NewContext → JS_Eval → while (JS_ExecutePendingJob(rt, &pctx) == 1) → JS_FreeContext → JS_FreeRuntime:

JSRuntime *rt = JS_NewRuntime();
JSContext *ctx = JS_NewContext(rt);
JSValue v = JS_Eval(ctx, code, strlen(code), "<in>", JS_EVAL_TYPE_GLOBAL);
JS_FreeValue(ctx, v);
JSContext *pctx; int st;
while ((st = JS_ExecutePendingJob(rt, &pctx)) == 1) { }
JS_FreeContext(ctx);
JS_FreeRuntime(rt);   // never aborts

Clean at 200k and 500k objects, with asserts verified live (NDEBUG not defined). Also clean:

variation	result
-O1, -O2, -Oz, -Oz -flto	clean
with and without -fwrapv	clean
-DCONFIG_STACK_CHECK defined	clean
JS_NewContextRaw + exactly DefaultIntrinsics' subset (no RegExpCompiler, no WeakRef) instead of JS_NewContext	clean
JS_SetMaxStackSize small enough to force a stack-overflow throw	throws, but still frees clean — no leak
current bellard/quickjs master (2026-06-04) via the qjs CLI	clean

So: the vendored engine's GC, the -fwrapv/LTO/optimization axis, the raw-context intrinsic subset, and stack-overflow error paths are all ruled out as causes. Meanwhile the WASM build aborts at 100k on wasmfile-release-sync, wasmfile-debug-sync, ng-wasmfile-release-sync and ng-wasmfile-debug-sync — i.e. across both engines and both optimization levels — which also rules out "release-only miscompilation".

I also read QTS_ExecutePendingJob, QTS_NewRuntime and QTS_NewContext in c/interface.c and could not find a leaked JSValue: the success path returns jsvalue_to_heap(JS_NewFloat64(...)) (not a GC object) and the exception path's handle is disposed by DisposableFail on the JS side.

Two build discrepancies

Neither is confirmed as the cause — I could not get an emscripten toolchain running locally to test them — but both are places where the WASM build diverges from what quickjs expects:

1. -DCONFIG_STACK_CHECK is force-enabled, which quickjs explicitly disables for emscripten. In vendor/quickjs/quickjs.c:

#if !defined(EMSCRIPTEN)
/* enable stack limitation */
#define CONFIG_STACK_CHECK
#endif

but packages/variant-quickjs-wasmfile-release-sync/Makefile has:

QUICKJS_DEFINES:=-D_GNU_SOURCE -DCONFIG_VERSION=\"$(QUICKJS_CONFIG_VERSION)\" -DCONFIG_STACK_CHECK

Because the -D wins, stack checking is active in the WASM builds against upstream's intent. That matters for this bug specifically because rt->stack_top is captured wherever JS_NewRuntime is called, while jobs run from a different host→WASM entry point (QTS_ExecutePendingJob) — so the frame address compared against stack_limit during a job need not be commensurable with the one recorded at runtime creation. That is also the only mechanism I found that would naturally distinguish "inside a promise job" from "synchronous", which is this bug's sharpest discriminator.

The cheap test, for anyone with the toolchain: drop -DCONFIG_STACK_CHECK from the variant Makefiles and re-run the reproducer.

2. js_def_malloc_usable_size returns 0 under emscripten, so malloc_size accounting only ever adds MALLOC_OVERHEAD per allocation:

#elif defined(EMSCRIPTEN)
    return 0;

That degrades js_trigger_gc's threshold logic in WASM only, which would explain why the abort is allocation-volume dependent in WASM and not natively. On its own it should only change GC timing, not correctness — but it does mean GC runs at different points in the WASM build than in any native build, so it is a plausible enabler rather than the fault itself.

Environment

macOS darwin arm64, Node v24.14.0, clang from Xcode; quickjs-emscripten 0.32.0; vendored quickjs 2025-09-13.

I don't have a working emscripten setup to go further. Happy to run any experiment against the published WASM builds, or to test a patched variant if someone can publish one.

[jackkav]

Follow-up that should save someone a wrong turn: there are two distinct failure modes behind this assertion, and runtime.setMaxStackSize() fixes one of them and not the other. My original report is only about the second.

Measured on @jitl/quickjs-wasmfile-release-sync 0.32.0, each row a fresh process:

trigger	setMaxStackSize(256 * 1024)	result
unbounded guest recursion, inside a job	absent	host RangeError: Maximum call stack size exceeded out of executePendingJobs, then the gc_obj_list abort on dispose
unbounded guest recursion, top-level (no job)	absent	host RangeError escapes evalCode and kills the process before dispose is even reached
unbounded guest recursion, either	present	QuickJS's own InternalError — catchable by the guest — and a clean dispose
~200k objects allocated inside a promise job	absent	abort
~200k objects allocated inside a promise job	present	still aborts

So:

1. The recursion mode is a stack-check calibration problem, and it is host-fixable. js_check_stack_overflow probes __builtin_frame_address(0) against rt->stack_limit. Under emscripten that address lives in linear memory, while guest recursion actually consumes the WASM call stack, which the probe can't see — so with the default JS_DEFAULT_STACK_SIZE (1MB) the check under-counts and the real WASM stack (-s STACK_SIZE=5MB) blows first. Note quickjs.c deliberately opts out of this on emscripten:

#if !defined(EMSCRIPTEN)
/* enable stack limitation */
#define CONFIG_STACK_CHECK
#endif

but the variant Makefiles force it back on:

QUICKJS_DEFINES:=-D_GNU_SOURCE -DCONFIG_VERSION=\"$(QUICKJS_CONFIG_VERSION)\" -DCONFIG_STACK_CHECK

Calling setMaxStackSize(256 * 1024) shrinks stack_limit enough that the under-counting probe trips before the real stack does, which is why it works — it is compensating for a miscalibrated measurement rather than measuring the right thing. Might be worth either not forcing -DCONFIG_STACK_CHECK for emscripten builds, or shipping a WASM-appropriate default stack size so consumers don't each have to discover this constant. (We've taken the setMaxStackSize route downstream in the meantime.)

2. The allocation mode in this issue is not stack-related at all. The guest script completes normally — __k = 200000, no InternalError, no host RangeError — and only dispose() aborts. setMaxStackSize makes no difference at any value I tried. This also retracts the -DCONFIG_STACK_CHECK suspicion I raised earlier in this issue: a correctly-firing stack check doesn't help here, and nothing in this reproducer approaches any stack limit.

Also, for whoever picks this up: js_def_malloc_usable_size returns 0 under emscripten, so malloc_size/malloc_count accounting — and therefore GC trigger timing — is degraded in WASM builds only. That's still my best guess for why this mode is allocation-volume dependent in WASM and never reproduces natively (the identical vendored source built natively is clean at 500k objects, at every optimization level, with and without -fwrapv, and with CONFIG_STACK_CHECK defined). Unverified — I don't have an -sASSERTIONS/DUMP_LEAKS build to confirm it.