Bug 289009 – IPInt segfault or out-of-bounds exception on Linux x86_64 running porffor

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Ben Grant]

Steps to reproduce:

- Clone https://github.com/190n/porffor.git and check out the "webkit" branch
- Install dependencies ("bun install" or "npm install")
- Run either:
/path/to/jsc -m --thresholdForBBQOptimizeAfterWarmUp=9999 --thresholdForBBQOptimizeSoon=9999 --thresholdForOMGOptimizeAfterWarmUp=9999 --thresholdForOMGOptimizeSoon=9999 runner/index.js
(for a single attempt)
bun run-porffor.js 500 /path/to/jsc -m --thresholdForBBQOptimizeAfterWarmUp=9999 --thresholdForBBQOptimizeSoon=9999 --thresholdForOMGOptimizeAfterWarmUp=9999 --thresholdForOMGOptimizeSoon=9999
(to run a bunch of attempts and print status)

Increasing the JIT thresholds makes this issue reproduce more reliably since this bug seems to be exclusive to the IPInt interpreter. With either --jitPolicyScale=0 or --useWasmIPInt=0, the issue does not happen anymore. I couldn't run the script with Wasm JIT disabled entirely because it contains SIMD code:

    CompileError: WebAssembly.Module doesn't parse at byte 100: wasm-simd is not enabled, in function at index 27 (evaluating 'new WebAssembly.Module(wasm)')

I used a JSCOnly Release build of webkit 291257@main on Ubuntu 24.04 inside WSL. Out of 500 attempts, in 15 cases the executable was terminated by SIGSEGV and in 2 cases it threw an exception:

    RuntimeError: Out of bounds memory access (evaluating 'wasm.apply(this, arguments)')

Unfortunately, I haven't been able to get a stack trace from the JSC shell because core dumps don't seem to work in WSL, but a stack trace from the same code crashing in Bun is:

    ld-temp.o:0: wasm_trampoline_wasm_ipint_call_wide32
    ld-temp.o:0: wasm_trampoline_wasm_ipint_call_wide32
    ld-temp.o:0: wasm_trampoline_wasm_ipint_call_wide32
    1 unknown/js code
    ld-temp.o:0: llint_op_call_varargs
    ld-temp.o:0: llint_op_call_wide16
    ld-temp.o:0: llint_call_javascript
    Interpreter.cpp:1680: JSC::AbstractModuleRecord::evaluate

I've only been able to consistently repro this on Linux x86_64. On aarch64, it does not seem to happen at all. On macOS x86_64 (in Rosetta) I have seen very occasional failures, but they seem much rarer than on Linux. I don't know if this is due to a difference in WebKit, or due to CPU performance or something (I'm guessing that whether this test fails relates to which functions get JIT compiled vs. executed in the interpreter).

This was originally reported to Bun at https://github.com/oven-sh/bun/issues/17870.

[Radar WebKit Bug Importer]

<rdar://problem/146696992>

[Mark Lam]

According to https://github.com/oven-sh/bun/issues/17870, this issue is a clone of https://github.com/oven-sh/bun/issues/17841.

[Ben Grant]

Not certain, but I believe they're the same or similar. I reported the Porffor issue here because the PGlite one is harder to reproduce in WebKit.

[Mark Lam]

We're not able to reproduce this Porffor issue.  This may be a Linux specific thing.  Are you able to reproduce it on a Mac?

[Ben Grant]

I can't get it to repro on macOS with Rosetta. I think either it's Linux-specific or the conditions needed to repro on macOS are different (even on Linux the repro is very finicky, so it could be down to CPU performance or OS scheduling).

[Mark Lam]

Maybe folks with access to Linux can see if they can look into this.  However, on macOS side, this bug is not actionable if there's no reliable repro, and so far, no one has even been able to reproduce it once on ay HW or Rosetta.  So, this looks like a Linux issue.

[Yusuke Suzuki]

Is this still happening on Trunk? We landed various IPInt improvement / bugfixes, and I wonder if this is already fixed.
I tried running it on Ubuntu with ToT, however, I cannot reproduce the crash.

[Ben Grant]

Can no longer reproduce on Linux x64 as of 293373@main -- thank you all!

[Yusuke Suzuki]

Nice! Thank you for confirming!