setMemoryLimit bounds a single allocation, not a runtime's total — large strings and typed arrays never accumulate #271

Activity

1. josefguenther commented on Sep 3, 2026

   

   josefguenther

   on Sep 3, 2026

   Author

   More actions

   Root cause found — it is upstream in cutils.h, and it is not large-block-specific

   Follow-up on my own report. I traced this and two claims in my original write-up were
   wrong, so I want to correct them before anyone acts on the hypothesis.

   It is not JS_MALLOC_LARGE_BLOCKS_ONLY

   That macro does not appear in quickjs-ng 0.12.1 or 0.16.2 at all. The defect is in
   cutils.h, in code both engine lineages share:

   static inline size_t js__malloc_usable_size(const void *ptr) {
   #if   defined(__APPLE__)   return malloc_size(ptr);
   #elif defined(_WIN32)      return _msize((void *)ptr);
   #elif defined(__linux__) || defined(__ANDROID__) || defined(__CYGWIN__) \
      || defined(__FreeBSD__) || defined(__GLIBC__)
                              return malloc_usable_size((void *)ptr);
   #else                      return 0;      // ← emscripten (musl) lands here
   #endif
   }

   def_malloc_funcs installs it, and js_malloc_rt does:

   if (unlikely(s->malloc_size + size > s->malloc_limit - 1))
       return NULL;                                              // checks the REQUESTED size
   s->malloc_size += rt->mf.js_malloc_usable_size(ptr) + MALLOC_OVERHEAD;   // adds 0 + 8

   The check reads the real requested size; the accumulator advances by a constant 8 bytes
   per allocation (MALLOC_OVERHEAD, 8 on every platform but Apple). That single asymmetry
   explains every row in my table: one allocation above the limit is refused because the check
   is honest, and no number of sub-limit allocations ever accumulates because the accounting
   is not.

   It is not "large blocks bypass accounting while the object heap is bounded"

   This is the part I got wrong. Nothing is byte-accounted on these platforms. The object
   loop stops not because bytes were tracked but because it exhausts a count budget: at 8
   bytes per allocation, an 8 MB limit permits ~1,048,576 allocations, and ~311k small objects
   is roughly that many allocations once each object's own slots and strings are counted.

   The limit has degenerated into "at most limit/8 simultaneous allocations, each
   individually smaller than limit" — a count budget wearing a byte budget's name.

   Confirming evidence: 200,000 × 600-byte strings — not "large blocks" under any definition —
   also never stop, reaching 114 MB live under an 8 MB limit.

   Measured independently of emscripten

   I reproduced all of this on a wasm32-wasi build of quickjs-ng compiled directly with
   wasi-sdk 25, no emscripten anywhere. wasm32-wasi falls to the same #else, and the
   results match yours row for row — including the small-object loop stopping at exactly
   311,073, which is what identifies the shared branch rather than a packaging difference.

   So this reproduces on both engine lineages and outside emscripten entirely. It is a
   platform-support gap in upstream cutils.h.

   0.16.2 is partially fixed, by accident of a different change

   ng 0.16.2's arena byte-accounts allocations ≤ 512 B from its own size class and only falls
   back to the broken js__malloc_usable_size for larger ones. The tell is that its
   small-object loop stops at 115,726 rather than 311,073 — genuinely byte-driven now.
   Bulk allocations are still unbounded: 60 × 1 MB under an 8 MB limit still all succeed.

   The fix, verified by rebuild

   Add __wasi__ (and, for this package, emscripten) to the branch, and to the <malloc.h>
   include selector at the top of the same file. wasi-libc declares malloc_usable_size in
   malloc.h and defines it in libc.a; emscripten's musl provides it too.

   I patched a local copy and rebuilt with an otherwise-identical toolchain and build line.
   Every row becomes correct:

   probe (8 MB limit)	before	after
   1 × 7 MB Uint8Array	allowed	allowed
   1 × 8 MB Uint8Array	refused	refused
   2 × 7 MB Uint8Array	allowed (14 MB live)	refused
   60 × 1 MB Uint8Array	all allowed (60 MB)	refused
   200k × 600-byte strings	no stop, 114 MB	refused
   runaway push(new Uint8Array(1MB)) under 32 MB	ran to 1022 MB	stops at 31 MB, heap tops out at 32.19 MB

   On computeMemoryUsage() reporting the total accurately

   Both are true and they are different fields. JS_ComputeMemoryUsage walks the heap and adds
   abuf->byte_length and string bytes into memory_used_size, which stays accurate
   throughout — 60.01 MB for 60 × 1 MB, 1022 MB for the runaway. Enforcement compares against
   malloc_size, which is the field that never advances. The accounting genuinely does see
   what the enforcement ignores; they simply are not the same counter.

   Suggested disposition

   The fix belongs in quickjs-ng (and bellard/quickjs, which shares the file). I am opening a PR
   upstream. Leaving this issue open in case you would rather patch the vendored copy in the
   meantime, since setMemoryLimit currently provides no byte bound on any emscripten build —
   your call whether that is worth carrying or whether tracking the upstream fix is enough.
2. josefguenther

   added a commit that references this issue on Sep 13, 2026

   Fix JS_SetMemoryLimit byte accounting on WASI

   ...

   0ffc652
3. saghul

   added a commit that references this issue on Sep 13, 2026

   Fix JS_SetMemoryLimit byte accounting on WASI

   ...

   0fdea21