Workaround for a TextDecoder bug in Safari causing a RangeError to be thrown #4472
Conversation
| @@ -11,16 +11,16 @@ | |||
| (type (;9;) (func (param i32 f64))) | |||
| (import "./reference_test_bg.js" "__wbindgen_init_externref_table" (func (;0;) (type 0))) | |||
| (func $__wbindgen_realloc (;1;) (type 8) (param i32 i32 i32 i32) (result i32)) | |||
| (func $__wbindgen_malloc (;2;) (type 6) (param i32 i32) (result i32)) | |||
There was a problem hiding this comment.
I am not sure why I needed these changes. I am using rustc 1.86.0, maybe I should be using another version?
bes
force-pushed
the
fix-safari-textdecoder-bug
branch
from
06346fa to
1a75ba6
Compare
|
Some unrelated clippy lints are failing, has CI rustc been updated without updating the code? |
|
There don't seem to be any tests (generated .js-files) that use the non-browser path of |
… thrown `TextDecoder` in Safari has a limitation that causes it to throw `RangeError` after decoding more than 2GiB of data. This causes long running wasm programs that need to use `TextDecoder` to crash and start throwing `RuntimeError` with the message "Out of bounds memory access". We work around the issue by tracking how much data has been decoded by any given `TextDecoder`, and replace it when it comes close to 2GiB, deducting a small margin of 1MiB which has been empirically shown to reduce the likelihood of miscounting (for unknown reasons) causing a `RangeError` to be thrown. This commit also adds stricter handling of the kind of declaration used for TextDecoder and TextEncoder - TextDecoder always uses let because it needs to be mutable, and TextEncoder always uses const because it doesn't need to be mutable. Fixes wasm-bindgen#4471
bes
force-pushed
the
fix-safari-textdecoder-bug
branch
from
1a75ba6 to
20a27e6
Compare
@daxpedda do you have any input on these? The PR works around a critical bug on Safari and would be very useful for many people! |
|
We've been running this fix in production for a week now, and the results are encouraging. Screenshots from Sentry. Ignore the first column, it's low because of a quirk in how Sentry does data cutoff... 
Can you guess which day the fix went out? |
TextDecoderin Safari has a limitation that causes it to throwRangeErrorafter decoding more than 2GiB of data. This causes long running wasm programs that need to useTextDecoderto crash and start throwingRuntimeErrorwith the message "Out of bounds memory access".We work around the issue by tracking how much data has been decoded by any given
TextDecoder, and replace it when it comes close to 2GiB, deducting a small margin of 1MiB which has been empirically shown to reduce the likelihood of miscounting (for unknown reasons) causing aRangeErrorto be thrown.This commit also adds stricter handling of the kind of declaration used for TextDecoder and TextEncoder - TextDecoder always uses let because it needs to be mutable, and TextEncoder always uses const because it doesn't need to be mutable.
Fixes #4471