Problems with "wasm-webapi" tests and V8 >= 11.2 #47297

targos · 2023-03-29T15:28:33Z

There seems to be issues with WASM streaming compilation on ARM since V8 11.2.

We had to disable these tests because they are somewhat flaky (sometimes they hang):

targos · 2023-03-30T07:22:21Z

I cannot reproduce the hang on my M2 mac, but I got this:

$ tools/test.py parallel/test-wasm-web-api --repeat 100 -j 8
=== release test-wasm-web-api ===
Path: parallel/test-wasm-web-api
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

  Comparison {
    code: 'ERR_WEBASSEMBLY_RESPONSE',
+   message: "WebAssembly response has unsupported MIME type 'text/plain'",
-   message: /^WebAssembly response has status code 418$/,
    name: 'TypeError'
  }
    at async Promise.all (index 1)
    at async /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js:177:3 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: TypeError [ERR_WEBASSEMBLY_RESPONSE]: WebAssembly response has unsupported MIME type 'text/plain'
      at new NodeError (node:internal/errors:399:5)
      at node:internal/wasm_web_api:30:13
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
    code: 'ERR_WEBASSEMBLY_RESPONSE'
  },
  expected: {
    name: 'TypeError',
    code: 'ERR_WEBASSEMBLY_RESPONSE',
    message: /^WebAssembly response has status code 418$/
  },
  operator: 'rejects'
}

Node.js v20.0.0-pre
Command: out/Release/node /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js


=== release test-wasm-web-api ===
Path: parallel/test-wasm-web-api
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

  Comparison {
+   message: 'fetch failed',
-   code: 'ERR_WEBASSEMBLY_RESPONSE',
-   message: "WebAssembly response has unsupported MIME type 'application/wasm;'",
    name: 'TypeError'
  }
    at async Promise.all (index 0)
    at async /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js:155:3 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: TypeError: fetch failed
      at Object.fetch (node:internal/deps/undici/undici:11457:11) {
    cause: HTTPParserError: Expected HTTP/
        at Parser.execute (node:internal/deps/undici/undici:9393:19)
        at Parser.readMore (node:internal/deps/undici/undici:9352:16)
        at Socket.onSocketReadable (node:internal/deps/undici/undici:9660:14)
        at Socket.emit (node:events:511:28)
        at emitReadable_ (node:internal/streams/readable:598:12)
        at process.processTicksAndRejections (node:internal/process/task_queues:81:21) {
      code: 'HPE_INVALID_CONSTANT',
      data: '\x00\x00\x00H{"id":2197,"num":0,"params":"AAAAAgAwAAADAAAAAAAAAAACykjJIQ==","type":2}'
    }
  },
  expected: {
    name: 'TypeError',
    code: 'ERR_WEBASSEMBLY_RESPONSE',
    message: "WebAssembly response has unsupported MIME type 'application/wasm;'"
  },
  operator: 'rejects'
}

Node.js v20.0.0-pre
Command: out/Release/node /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js


[01:07|% 100|+  98|-   2]: Done

Failed tests:
out/Release/node /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js
out/Release/node /Users/mzasso/git/nodejs/v8-next-update/test/parallel/test-wasm-web-api.js

targos · 2023-04-04T09:30:23Z

It's not only on ARM: https://ci.nodejs.org/job/node-test-commit-linux-containered/37077/nodes=ubuntu1804_sharedlibs_shared_x64/

mhdawson · 2023-04-05T19:43:02Z

Failured on windows as well https://ci.nodejs.org/job/node-test-binary-windows-js-suites/20205/RUN_SUBSET=0,nodes=win11-arm64-COMPILED_BY-vs2019-arm64/testReport/junit/(root)/wpt/test_wasm_webapi/

targos · 2023-04-06T08:07:30Z

There's discussion about this issue in https://bugs.chromium.org/p/v8/issues/detail?id=13902 and it is most likely a problem in Node.js.
/cc @nodejs/cpp-reviewers

It introduces process hangs on some platforms because Node.js doesn't tear down V8 correctly. Disable it while we work on a solution. Refs: nodejs#47297 Refs: https://bugs.chromium.org/p/v8/issues/detail?id=13902

It introduces process hangs on some platforms because Node.js doesn't tear down V8 correctly. Disable it while we work on a solution. Refs: #47297 Refs: https://bugs.chromium.org/p/v8/issues/detail?id=13902 PR-URL: #47450 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: [wasm] Simplify CompileJSToWasmWrapperJob This CL merges some of AsyncCompileJSToWasmWrapperJob and CompileJSToWasmWrapperJob into a common base class. Both jobs now loop on a vector with an atomic index. Bug: chromium:1423615 Change-Id: I7bb9cb2a57d8b659766c01e20e38d1b859d3a987 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4347597 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/main@{#86675} Refs: v8/v8@a8a11a8 PR-URL: #47610 Refs: #47297 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: [wasm] Fix deadlock in async wrapper compilation If compilation is cancelled while wrapper compilation is running, the tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return immediately, but {GetMaxConcurrency} will still return a positive value. Hence {Join()} will spawn another task, resulting in a livelock. We could fix this by checking for cancellation in {GetMaxConcurrency}, but that requires taking the compilation state lock. So this CL fixes the issue by dropping the number of outstanding compilation units by to (basically) zero. We can't unconditionally drop to zero because another thread might concurrently execute a wrapper compilation and still call {CompleteUnit} afterwards. Hence only drop outstanding units by the amount of not-yet-started units. R=jkummerow@chromium.org Bug: v8:13858 Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#87143} Refs: v8/v8@5f025d1 PR-URL: #47610 Refs: #47297 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: [wasm] Simplify CompileJSToWasmWrapperJob This CL merges some of AsyncCompileJSToWasmWrapperJob and CompileJSToWasmWrapperJob into a common base class. Both jobs now loop on a vector with an atomic index. Bug: chromium:1423615 Change-Id: I7bb9cb2a57d8b659766c01e20e38d1b859d3a987 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4347597 Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/main@{#86675} Refs: v8/v8@a8a11a8 PR-URL: #47610 Refs: #47297 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: [wasm] Fix deadlock in async wrapper compilation If compilation is cancelled while wrapper compilation is running, the tasks spawned for the {AsyncCompileJSToWasmWrapperJob} will return immediately, but {GetMaxConcurrency} will still return a positive value. Hence {Join()} will spawn another task, resulting in a livelock. We could fix this by checking for cancellation in {GetMaxConcurrency}, but that requires taking the compilation state lock. So this CL fixes the issue by dropping the number of outstanding compilation units by to (basically) zero. We can't unconditionally drop to zero because another thread might concurrently execute a wrapper compilation and still call {CompleteUnit} afterwards. Hence only drop outstanding units by the amount of not-yet-started units. R=jkummerow@chromium.org Bug: v8:13858 Change-Id: I5398ef370da2e7f212ca772fd1f87f659929dd6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4437531 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#87143} Refs: v8/v8@5f025d1 PR-URL: #47610 Refs: #47297 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

It introduces process hangs on some platforms because Node.js doesn't tear down V8 correctly. Disable it while we work on a solution. Refs: nodejs#47297 Refs: https://bugs.chromium.org/p/v8/issues/detail?id=13902 PR-URL: nodejs#47450 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>

It introduces process hangs on some platforms because Node.js doesn't tear down V8 correctly. Disable it while we work on a solution. Refs: nodejs/node#47297 Refs: https://bugs.chromium.org/p/v8/issues/detail?id=13902 PR-URL: nodejs/node#47450 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Michael Dawson <midawson@redhat.com> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>