Bug 286266 – WebAssembly code spuriously encounters RangeError(BadValue) and then "Out of bounds memory access"

• Status: NEW
• Component: WebAssembly

[Erik Zivkovic]

We have a WebAssembly library written in Rust that contains code that is shared between Desktop (native), iOS (native), and Web. We haven't detected any crashes in the native code or crashes on Chrome or FireFox for our WebAssembly code. However, our Sentry integration reports that a number of our Safari users, on multiple sub-versions of 18 and 17 as well as OS's (iOS, iPadOS, macOS of different versions) run into the following behavior:

1. Encounter RangeError: BadValue
2. Every JS to WASM call after reports "Out of bounds memory access"

The code that encounters the RangeError looks like this

```
function makeMutClosure(arg0, arg1, dtor, f) {
    const state = { a: arg0, b: arg1, cnt: 1, dtor };
    const real = (...args) => {
        // First up with a closure we increment the internal reference
        // count. This ensures that the Rust closure environment won't
        // be deallocated while we're invoking it.
        state.cnt++;
        const a = state.a;
        state.a = 0;
        try {
            // *********************** Sentry stack starts here *****************
            return f(a, state.b, ...args);
        } finally {
            if (--state.cnt === 0) {
                wasm.__wbindgen_export_4.get(state.dtor)(a, state.b);
                CLOSURE_DTORS.unregister(state);
            } else {
                state.a = a;
            }
        }
    };
    real.original = state;
    CLOSURE_DTORS.register(real, state, state);
    return real;
}

function __wbg_adapter_50(arg0, arg1, arg2) {
    // *********************** Then goes here *****************
    wasm.__wbindgen_export_5(arg0, arg1, addHeapObject(arg2));
}

export function __wbg_setmethod_cfc7f688ba46a6be(arg0, arg1, arg2) {
     // *********************** Finally encounters a RangeError here *****************
    getObject(arg0).method = getStringFromWasm0(arg1, arg2);
};

function getStringFromWasm0(ptr, len) {
    ptr = ptr >>> 0;
    return cachedTextDecoder.decode(getUint8ArrayMemory0().subarray(ptr, ptr + len));
}
```

Once the bug has triggered the tab needs to be restarted.

I have tried to get help from the wasm-bindgen community (https://github.com/rustwasm/wasm-bindgen/discussions/4185) but without any solid results.

It is entirely possible that there is a bug in our code, but it has yet to trigger or be reported on any other wasm runtime or native deployment.

I have successfully triggered the bug myself, as have a few of my colleagues but it is hard and you have to leave the software running for quite a long time (hours). It seems like our customers can trigger the bug much faster though, since we start getting bug reports in Sentry almost immediately after a new software deployment. Enough of our Safari users run into this bug (About 100 users of 10,000 MAU Safari users) that I consider it to be a problem for us.

It's proprietary software, but I'd be happy to give anyone that needs access a free account to reproduce the bug. I have not been able to create a minimal reproduction since there are a lot of moving parts.

Thank you.

[Radar WebKit Bug Importer]

<rdar://problem/143697823>

[Keith Miller]

Hi, thanks for the report!

Unfortunately, I don't know enough about how Rust is compiled to wasm to know if there's a bug in your source or not. Given the issue happens in Safari and not in others with the same wasm blob/machine (I say machine since if you're using threads ARM vs x86 memory model issues come into play) we'd probably consider that a bug on our end. Feel free to email me at [e-mail] to set up a test account. That said, if you're willing to help diagnose the issue too, these could help speed things along: 

1) Do you use threads/Workers/SharedArrayBuffer? Does this reproduce without that?
2) Can you provide the `.stack` property off the first RangeError that's thrown?
3) Is this issue particularly prevalent on any particular device (I assume this is all Mac)?

Given that you said this takes hours to reproduce I'm inclined to think it's not a JIT bug (unless it's some very cold code in your wasm blob).

[Erik Zivkovic]

Hello!

Thank you for your reply!

I will send you an e-mail shortly regarding getting an account set up.

To answer your questions:
1. No we don't use Threads, Workers, or SharedArrayBuffer.
2. That property doesn't get sent to Sentry so I will have to try and reproduce the bug myself to see if I can get a hold of it.
3. It's mac and iOS. Since a few macOS versions ago it's not possible to see the exact macOS version, or platform (ARM/x86) in Sentry, I'm guessing because it's hidden by Safari. Sentry says 94% mac, 4% iPhone, 1% iPad.

Best Regards,
Erik

[Erik Zivkovic]

Hello, I have been getting more and more reports of this error, and I have finally been able to get somewhere. Reproducing the error is time consuming, so I am using a setup where I run 6+ instances of Safari at the same time to try to hit the error faster.

I was able to monkey patch the xx_wasm_bg.js file which is emitted from wasm-bindgen / wasmpack (Rust tools) to add a try / catch wrapper around the offending site.

```
function getStringFromWasm0(ptr, len) {
    try {
        ptr = ptr >>> 0;
        return cachedTextDecoder.decode(getUint8ArrayMemory0().subarray(ptr, ptr + len));
    } catch (e) {
        console.error(e);
        debugger;
        throw e;
    }
}
```

The error occurs on the line `return cachedTextDecoder.decode(getUint8ArrayMemory0().subarray(ptr, ptr + len));` with the following values:
ptr: 46143872
len: 36

The console.error says

```
RangeError: Bad value
decode
getStringFromWasm0 — xx_wasm_bg.js:143
__wbindgen_string_new — xx_wasm_bg.js:2499
<?>.wasm-function[]
<?>.wasm-function[]
<?>.wasm-function[]
<?>.wasm-function[]
<?>.wasm-function[]
<?>.wasm-function[]
myFunctionSomething — xx_wasm_bg.js:765
// snip...
```

I was able to add some watch expressions, notably:

`getUint8ArrayMemory0().subarray(46143872, 46143872+36)` which produces this array:

```
56, 57, 52, 49, 55, 53, 102, 56, 45, 51, 48, 98, 49, 45, 52, 49, 55, 50, 45, 57, 51, 55, 55, 45, 55, 97, 57, 99, 56, 53, 50, 48, 56, 98, 102, 48]
```

Trying to decode the array using the `cachedTextDecoder` yields the same error again.

So I did this in a new Safari console:

```
let c = new TextDecoder('utf-8', { ignoreBOM: true, fatal: true });
let data = [56, 57, 52, 49, 55, 53, 102, 56, 45, 51, 48, 98, 49, 45, 52, 49, 55, 50, 45, 57, 51, 55, 55, 45, 55, 97, 57, 99, 56, 53, 50, 48, 56, 98, 102, 48];
c.decode(new Uint8Array(data));
```

Which yields this in the unrelated Safari console:
```
"894175f8-30b1-4172-9377-7a9c85208bf0"
```

A perfectly good v4 UUID.

So what's happening here, I think, is that _somehow_ TextDecoder has gotten the fritz, and is throwing a Range Error: Bad Value, when it should just be happily decoding an array into a UUID.

Please let me know what you think.

[Erik Zivkovic]

I will keep the Safari window with the breakpoint open for as long as I can, so if there are any follow-up things you want me to do, please let me know ASAP.

[Erik Zivkovic]

To reproduce I opened 6 Safari windows and let them run in parallel until at least one hit a debugger statement in the monkey patch. Since writing the above bug report, one more has hit the debugger, with another range and another perfectly good UUID:

```
new TextDecoder('utf-8', { ignoreBOM: true, fatal: true }).decode(getUint8ArrayMemory0().subarray(70636528, 70636528+36))
```

Which gives "0542a584-55e2-415f-81c2-976de148bde6"

[Erik Zivkovic]

Browser: Safari Version 18.4 (20621.1.15.11.10)
Hardware: MBP 16" Apple M2 Max 32 GB
macOS: 15.4 (24E248)

[Erik Zivkovic]

Probably a duplicate of https://bugs.webkit.org/show_bug.cgi?id=280593 ?