Investigate persistent Windows test failure on test.wasi/test-return-on-exit

[Trott]

• Test: test.wasi/test-return-on-exit
• Platform: win2012r2
• Console Output:

00:30:50 not ok 778 wasi/test-return-on-exit # TODO : Fix flaky test
00:30:50   ---
00:30:50   duration_ms: 49.248
00:30:50   severity: flaky
00:30:50   exitcode: 134
00:30:50   stack: |-
00:30:50     (node:972) ExperimentalWarning: WASI is an experimental feature. This feature could change at any time
00:30:50     (Use `node --trace-warnings ...` to show where the warning was created)
00:30:50     
00:30:50     <--- Last few GCs --->
00:30:50     
00:30:50     
00:30:50     <--- JS stacktrace --->
00:30:50     
00:30:50     FATAL ERROR: Zone Allocation failed - process out of memory
00:30:50   ...

• Build Links:

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/8229/RUN_SUBSET=3,nodes=win2012r2-COMPILED_BY-vs2019-x86/console and pretty much any other recent Jenkins CI run as the failure is persistent.

[Trott]

Refs: #36139 (comment)

[Trott]

@nodejs/platform-windows

[Trott]

Since this apparently started happening with the V8 update to 8.8: @nodejs/v8

[targos]

Also @nodejs/wasi

[targos]

There's probably a real bug somewhere, because this only happens on a 32 bit system.

[Trott]

There's probably a real bug somewhere, because this only happens on a 32 bit system.

Any thoughts on how we can make some progress on this?

[Trott]

Refs: #36139 (comment)

@gengjiawen Any ideas on what to do here?

[Trott]

@nodejs/testing Any ideas for what we might be able to do in CI or elsewhere to figure this out?

[cjihrig]

I agree that this is probably a genuine bug since it only shows up on 32-bit Windows, and coincided with the V8 8.8 update (which had wasm related changes). The returnOnExit feature also relies on somewhat corner case behavior - monkey patching the WASI import to throw a JavaScript exception that WebAssembly can't catch.

Regarding the test - as a last resort, we could skip it on Windows. It looks like there are two test cases in test/wasi/test-return-on-exit.js. Can we identify which of them is causing the crash, or if splitting them into separate test files somehow mitigates the problem?

[targos]

https://ci.nodejs.org/job/node-test-commit-windows-fanned/41469/

Windows CI with targos@55e5b94

[cjihrig]

I re-ran the Windows CI a couple times as well. All failures were in test-return-on-exit-1, which contains the following code:

// Flags: --experimental-wasi-unstable-preview1
'use strict';
const common = require('../common');
const assert = require('assert');
const fs = require('fs');
const path = require('path');
const { WASI } = require('wasi');
const wasmDir = path.join(__dirname, 'wasm');
const modulePath = path.join(wasmDir, 'exitcode.wasm');
const buffer = fs.readFileSync(modulePath);

(async () => {
  // Verify that if a WASI application throws an exception, Node rethrows it
  // properly.
  const wasi = new WASI({ returnOnExit: true });
  wasi.wasiImport.proc_exit = () => { throw new Error('test error'); };
  const importObject = { wasi_snapshot_preview1: wasi.wasiImport };
  const { instance } = await WebAssembly.instantiate(buffer, importObject);

  assert.throws(() => {
    wasi.start(instance);
  }, /^Error: test error$/);
})().then(common.mustCall());

The main difference here is that wasi.wasiImport.proc_exit() is monkey-patched a second time here to throw an Error object, rather than throwing a Symbol as returnOnExit would normally.

[cjihrig]

I noticed another small difference that shouldn't have any impact. In the flaky test, the proc_exit() function is not bound to the WASI import. I ran cjihrig@32cb5b7 through the CI a few times, and haven't seen this test fail. Maybe I'm doing something wrong? If that does fix the flakiness, this seems like a probable bug in V8.