Bug 287297 – Wasm out-of-bounds exception running Solidity compiler under LLInt or IPInt x64

• Component: JavaScriptCore
• Status: RESOLVED FIXED

Created attachment 474162 [details]
JavaScript program loading and invoking the Solidity compiler Wasm module

Steps to reproduce:

Download attached bundled.js and compiler.wasm to the same directory
Run bundled.js in the JSC shell

Expected result: "TEST PASSED"
Actual result: "TEST FAILED RuntimeError: Out of bounds memory access (evaluating 'getWasmTableEntry(index)(a1,a2)')"

Solidity is a programming language with a compiler in C++, which they also distribute compiled to Wasm via emscripten.

This issue seems to only happen on x86_64 CPUs. I've seen it on a Linux machine running Arch Linux on an Intel i9-13900, and a MacBook Pro M3 Max on macOS 15.1.1 with Rosetta (I don't have an Intel Mac on hand; this could be a Rosetta issue but the Linux crash is not). I haven't gotten this issue to occur on any aarch64 machine.

I used a release JSCOnly build of WebKit commit 790c320807aa. This issue reproduces very consistently on my Linux machine with the default flags or with `--jitPolicyScale=0`. With `--useWasmIPInt=0`, it reproduces roughly once in 10 attempts. With `--useWasmIPInt=0 --jitPolicyScale=0` the test passes consistently. So the crash seems related to both Wasm interpreters.

This issue was originally reported to Bun at https://github.com/oven-sh/bun/issues/17146. I ported their example to run in either Bun or the JSC shell, and read the Wasm module from a separate file instead of a base64 string so that the JS code is a little less unwieldy. Bun disables IPInt by default so that reporter's results are consistent with my results using the JSC shell with `--useWasmIPInt=0`.

Created attachment 474163 [details]
Wasm build of the Solidity compiler

[Radar WebKit Bug Importer]

<rdar://problem/144890544>

Pull request: https://github.com/WebKit/WebKit/pull/40773

Thank you!

It seemed like this was affecting LLInt too, but it's possible I'm not fully understanding how the options affect which execution tiers are used. Will that PR also fix the out-of-bounds exceptions occasionally encountered running that script with --useWasmIPInt=0 (this is the default in Bun)?

It might also just be time for Bun to re-enable IPInt by default (we have been disabling it explicitly since https://github.com/WebKit/WebKit/pull/39029, because at the time we didn't want to do another WebKit upgrade just to get the changed default option, but I see quite a few bugs have been fixed and upstream WebKit has re-enabled IPInt by default now).

[EWS]

Committed 290589@main (c3dadf54693b): <https://commits.webkit.org/290589@main>

Reviewed commits have been landed. Closing PR #40773 and removing active labels.