Workaround for a TextDecoder bug in Safari causing a RangeError to be thrown #4472
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bes
commented
Apr 6, 2025
| @@ -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? |
bes
commented
Apr 7, 2025
|
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 rustwasm#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! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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