Safari (17.5 -> 18.0.1): "Out of bounds memory access" and "RangeError: Bad value"

[bes]

Hello! I have a wasm library bundled with a TypeScript SPA through Webpack, and errors are sent to Sentry.

I have a large sample size of users (20k+ daily) and a small percentage of them are hitting "Out of bounds memory access", but only on recent versions of Safari. About 100 Safari users are getting "Out of bounds memory access" and "RangeError: Bad value" originating somewhere in WebAssembly.

Once one of the errors hit one method, all of them start throwing these errors.

I know this is a bit vague, but I want to gauge the community's feeling for what this might be.

• Is this just a Safari thing, or is it something I am doing wrong?
• What are your best ideas for debugging / reproducing this? (I haven't been able to reproduce it yet)

Zero errors from non-WebKit browsers in Sentry over a period of 90 days.

[daxpedda]

See #3698, I hope a stacktrace can be a good start.
There are also tools for coredumping, though I'm unsure how up-to-date they are now.

[Liamolucko]

This sounds similar to #3474; we never managed to solve that though, so it isn't of much help.

[bes]

I can't be sure, but it seems like RangeError: Bad Value always happens before Out of bounds memory access and that it happens here:

export function __wbindgen_string_new(arg0, arg1) {
    const ret = getStringFromWasm0(arg0, arg1);
    return addHeapObject(ret);
};

So something inside the wasm blob calls__wbindgen_string_new in javascript, which crashes here, according to Sentry (but I can't know if it's 100% correct):

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

It doesn't show where it crashes inside getStringFromWasm0, it just looks like this:

[daxpedda]

Well, that's a good start! But its going to be quite hard without a reproduction or a stacktrace.

But presumably some invalid string is trying to be created, which is strange as its simply passing the pointer and length. Knowing where exactly this happens could help you debug it, e.g. you could simply print the pointer and length and compare it to a memory snapshot (not sure if Sentry sends this along as well).

Is your application by any chance consuming 2 GB or more? Maybe there is some issue in Safari around that.

[stephanemagnenat]

I have no idea whether my input is helpful, but with a Rustc that has multivalue and reference-types enabled by default (>= 1.82), I'm getting RuntimeError: Out of bounds table access (evaluating 't.crop_and_call(e,n,_)') where crop_and_call is an exported Rust function. I am getting this error in a web worker on Safari <= 16.3. My work-around has been to downgrade Rustc to 1.81, hopefully it solves the issue. It is hard to debug as this is optimized image-processing code running in production.

[bes]

This is another issue. Another way to solve this is to set strip = true in Cargo.toml under [profile.release] with a newer compiler. I don't know why, and it might not be a reliable workaround, but it works for now.

[bes]

This has been cooking for a long time, but I just managed to reproduce the bug locally and had time to do some digging. I still don't know 100% what is going on, but my latest investigation can be found here https://bugs.webkit.org/show_bug.cgi?id=286266 (Safari bug tracker)

Copied from the issue comment, which I wrote:

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.

[bes]

Found this issue: TextDecoder raises "RangeError: Bad value" exception after 2GB of text

Apparently, after processing 2GB of text, Safari's TextDecoder just stops working.

[bes]

I have written an issue #4471

[stephanemagnenat]

Awesome work! Thank you very very much!