Node.js 22.16.0 on Windows11-on-ARM is broken with respect to Wasm heap growth

[juj]

a.c

#include <pthread.h>
#include <stdlib.h>
#include <assert.h>

#define FINAL_HEAP_SIZE (64 * 1024 * 1024)

const char *_Atomic buffer = NULL;

void *thread_start(void *arg) {
  char *buf = malloc(FINAL_HEAP_SIZE);
  buf += FINAL_HEAP_SIZE - 1;
  *buf = 42;
  buffer = buf;
  return NULL;
}

int main() {
  pthread_t thr;
  int res = pthread_create(&thr, NULL, thread_start, NULL);
  while (!buffer);
  assert(*buffer == 42);
  return 0;
}

yields

C:\buildbot\win11-arm64-32gb-snapdragon-x\emscripten_win11_arm64\build\emscripten\main>emcc a.c -pthread -sALLOW_MEMORY_GROWTH -sINITIAL_MEMORY=32MB -sMAXIMUM_MEMORY=256MB -sMINIMAL_RUNTIME -g -Oz -o a.js
emcc: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]
emcc: warning: running limited binaryen optimizations because DWARF info requested (or indirectly required) [-Wlimited-postlink-optimizations]

C:\buildbot\win11-arm64-32gb-snapdragon-x\emscripten_win11_arm64\build\emscripten\main>%EMSDK_NODE% a.js
wasm://wasm/a.wasm-000f691e:1


RuntimeError: memory access out of bounds
    at a.wasm.__original_main (wasm://wasm/a.wasm-000f691e:wasm-function[19]:0x661)
    at a.wasm.main (wasm://wasm/a.wasm-000f691e:wasm-function[20]:0x684)
    at run (C:\buildbot\win11-arm64-32gb-snapdragon-x\emscripten_win11_arm64\build\emscripten\main\a.js:1022:3)
    at ready (C:\buildbot\win11-arm64-32gb-snapdragon-x\emscripten_win11_arm64\build\emscripten\main\a.js:48:5)
    at C:\buildbot\win11-arm64-32gb-snapdragon-x\emscripten_win11_arm64\build\emscripten\main\a.js:1071:5

Node.js v22.16.0

The test case is minimally reduced version of test other.test_pthread_growth which deterministically fails on Node.js on Windows 11 on ARM.

Only Node.js 22.16.0 fails. Node.js v24.7.0 works correctly.

[sbc100]

Do we know what the actual bug is here? Or why it effects only windows?

[juj]

I don't know.

To be precise, the issue doesn't occur on x64 Node.js 22.16.0. Only ARM64 version of Node.

[juj]

The out of bounds access itself takes place on expression *buffer on the line assert(*buffer == 42);. Removing that avoids the issue.