Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent exception: Failed to execute 'decode' on 'TextDecoder' #18034

Open
aharondavid opened this issue Oct 11, 2022 · 8 comments
Open

Comments

@aharondavid
Copy link

I get an inconsistent exception (running in main thread):
Uncaught TypeError: Failed to execute 'decode' on 'TextDecoder': The provided ArrayBufferView value must not be shared.

what can be the reason for that inconsistent exception behave?

Version of emscripten/emsdk:
emcc version: 3.1.9
Windows 11.
Chrome.

image

@sbc100
Copy link
Collaborator

sbc100 commented Oct 11, 2022

Can you share the full link command that you use? (so we can see which settings apply?)

@aharondavid
Copy link
Author

here:
C:\emsdk\upstream\emscripten\emcc.bat Emscripten/Debug/TEApiWrapper80_for_emscripten.o Emscripten/Debug/Main.o -ljpeg.Emscripten -lxml2 -lprjplg.Emscripten -lproj -lgdal -lgeos -lgeos_c -l3ds.Emscripten -lTerraExplorerX.Emscripten -lCore.Emscripten -l7zip.Emscripten -llibzip.Emscripten -lgisplg.Emscripten -lMptDll.Emscripten -lOpenGL.Emscripten -lPlgShell.Emscripten -lSLLogger.Emscripten -lSLLoggerLib.Emscripten -lSLStrings.Emscripten -lTerraCommon.Emscripten -lTerra.Emscripten -lTESWQ.Emscripten -lWFSPlugin.Emscripten -lsl_png.Emscripten -ldraco.Emscripten -lOpenCTM.Emscripten -lwebp.Emscripten -lMPTPlg.Emscripten -s ALLOW_TABLE_GROWTH -s WASM_BIGINT -s EXPORTED_RUNTIME_METHODS=ccall,cwrap -s EXPORTED_FUNCTIONS=_main -g --bind -s USE_PTHREADS -s ALLOW_MEMORY_GROWTH=1 -s PTHREAD_POOL_SIZE=50 -s EXIT_RUNTIME -s ASSERTIONS -s FETCH -s NO_DISABLE_EXCEPTION_CATCHING -O0 --preload-file com.skyline.terraexplorer -o C:/Projects/TerraExplorer_v8_0_0_Dev/SLSource/Emscripten/Debug/TEW/TerraExplorerApp.Emscripten.js -LC:/Projects/TerraExplorer_v8_0_0_Dev/SLSource/Emscripten/Debug/ -LC:/Projects/TerraExplorer_v8_0_0_Dev/SLSource/Emscripten/TerraExplorerApp.Emscripten/libs

@aharondavid
Copy link
Author

The bug is found - I had a string without a null terminate that pass to UTF8ToString.
(I got a warning about that in the console log, but, I didn't notice about it).

Thanks.

@juj
Copy link
Collaborator

juj commented Oct 13, 2022

I had a string without a null terminate that pass to UTF8ToString.

Hmm, I am a bit skeptical that would have been the root issue here, because even a non-nullterminated string should not raise an error like that to my understanding.

However there is an optimization that small enough strings use manual marshalling, and only large enough strings go through textdecoder.decode. This behavior would mask an issue like that. If you try marshalling larger strings (longer than 16 characters), the issue still might persist.

You can try to see if the issue comes back if you try marshalling a >16 chars long string? If so, you can try passing a linker argument -sTEXTDECODER=0 to work around that issue to see if that helps.

@aharondavid
Copy link
Author

aharondavid commented Oct 13, 2022

you right! the issue come back and -sTEXTDECODER=0 solve it.
Thank you very much!

I see that UTF8ArrayToString is not use in TextDecoder when compiling with that flag.
what are the disadvantages of using in that flag?
Do you know, maybe, why the error is inconsistent?

Actually, I sent to UTF8ToString a lot of strings that are longer then 1024 and even much longer.
Sometimes it's out of my control, for example, when using glShaderSource, one of its parameter is a string that
underline converted by UTF8ToString.

@juj
Copy link
Collaborator

juj commented Oct 14, 2022

When SharedArrayBuffer was coming, we had discussions with all kinds of web API working groups where it would make sense to allow a SharedArrayBuffer as an input. Some APIs got updated quite promptly (e.g. WebGL), and others got stuck in either editorial limbo or priority limbo. E.g. Web Audio API is frozen in time and decided not to accommodate this, and TextDecoder API did go through the change, but actual implementations stalled.

We used to unconditionally disable TEXTDECODER on SAB out of the box, though there was a refactor that adjusted this behavior, and then later some more refactors.

I suppose one of those commits have regressed this front, and you are now seeing a regression bug. I'll reopen this issue to track the regression.

In multithreaded enabled builds, using TEXTDECODER=0 is the correct thing to do for browsers that don't support TextDecoding from SharedArrayBuffers. Generally not using TextDecoder gives a micro-benchmarkable speed penalty when decoding large strings.

Which browser version are you testing on?

@juj juj reopened this Oct 14, 2022
@aharondavid
Copy link
Author

aharondavid commented Oct 14, 2022

Chrome version 106

@tocubed
Copy link

tocubed commented Nov 24, 2022

Hi all,

I also observed this error, chrome version 107. It happened very inconsistently for me.
I was able to break on exception and inspect what could be going wrong since the code there should already ensure a non-shared buffer is given to the decoder (by the if block in TextDecoderWrapper.decode).

image

A really strange result. What's more there are no iframes that I'm aware so I'm not sure what could cause it to fail detecting instanceof SharedArrayBuffer. I observed the function at other points and the if statement evaluated to true just fine.

The program I'm running calls UTF8ToString many times (most are for logging to console, but some are for sending strings to manipulate DOM, WebGL, etc.). When the issue did reproduce, it happened only a few select places, most notably not during logging, but generally when we are trying to update the DOM after a long running operation. Makes me suspect there is something specific about timing which allows this to happen. I would estimate it happens approximately 1/10000 calls to UTF8ToString.

Some of our testers reported it would reproduce more often if they had Grammarly extension enabled. That's as much as I know.

For now we have enabled -s TEXTDECODER=0

Best regards,
Priyank

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants