-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Comments
Can you share the full link command that you use? (so we can see which settings apply?) |
here: |
The bug is found - I had a string without a null terminate that pass to UTF8ToString. Thanks. |
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 |
you right! the issue come back and I see that UTF8ArrayToString is not use in TextDecoder when compiling with that flag. Actually, I sent to UTF8ToString a lot of strings that are longer then 1024 and even much longer. |
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 Which browser version are you testing on? |
Chrome version 106 |
Hi all, I also observed this error, chrome version 107. It happened very inconsistently for me. 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, |
Add Emscripten workaround for TextDecoder exception. emscripten-core/emscripten#18034
Add Emscripten workaround for TextDecoder exception. emscripten-core/emscripten#18034
* browser support * CMake: WASM should be tested and else left for Linux as before * Remove conflicting vcpkg.json files * Use existing base64 encoder * Check for emscripten before includes and declarations * Improve CMakeLists * Fix case-sensitivity issues * Implement bitlib and restore original .lua files bit operations * Support older protocols and improvements * Set correct numpad keys * Intercept all browser keys * Allow pasting and writing symbols with shift * Improve networking No need to reinvent the wheel * Reload page on client exit * Reduce CPU usage and connection improvements Drop g_ioService to avoid doing work during polling and make the thread sleep a bit if no message ready * Disable Emscripten's text decoder emscripten-core/emscripten#18034 * Basic mobile support - Handle touch events and longpress for right click - Check user agent to determine isMobile - Use VirtualKeyboardAPI to show keyboard (iOS not supported https://developer.mozilla.org/en-US/docs/Web/API/VirtualKeyboard_API) * Improve performance Drop manually swapping buffers to reduce CPU overhead * Case insensitive FS and properly return if websocket fails to be created * Fix Vorbis Linking (7cd3c82) * Allow gameWorld port to be set without rebuilding As servers and login servers are not adapted to send correct information when using the web client, it's necessary to override the world port and ip address that is received. Before, the world port was being forced to what was defined in the WEBPORT variable, not matter what port was informed when connect() was called. Now, you can override the port using lua (characterlist.lua) and avoid rebuilding the client. OBS: Port 7172 will still be overriden to 443 by the client. * Remove unused definition * Remove '&' #894 (comment) * Remove swapBuffers call, we no longer use it 3c6bc5a * Properly encode json #894 (comment) * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * c++17 remove file * Recommended improvements #894 (comment) #894 (comment) #894 (comment) #894 (comment) * Remove uneeded link libs * remove regex * Cleanup shell.html * Make compiling easier - We can now use vcpkg.json with an adapted cmake command (check guide) - Update overlay-ports to the current baseline * Add baseline to overlay-ports vcpkg.json files * Workflows: ignore overlay-ports vcpkg.json * Bot V8 basic fixes Adapt load() calls to lua 5.1 * Disable UIGraph while the browser building issue is not found * Fix broken regex * Fix broken regex * Fix compiling after include changes --------- Co-authored-by: Ivan Clementino <ivancarlos.clementino@gmail.com> Co-authored-by: Renato Machado <mehahx@gmail.com> Co-authored-by: Rodrigo Paixão <god.rodrigo@hotmail.com> Co-authored-by: Luan Luciano <luanluciano@outlook.com> Co-authored-by: divinity76 <divinity76@gmail.com>
* browser support * CMake: WASM should be tested and else left for Linux as before * Remove conflicting vcpkg.json files * Use existing base64 encoder * Check for emscripten before includes and declarations * Improve CMakeLists * Fix case-sensitivity issues * Implement bitlib and restore original .lua files bit operations * Support older protocols and improvements * Set correct numpad keys * Intercept all browser keys * Allow pasting and writing symbols with shift * Improve networking No need to reinvent the wheel * Reload page on client exit * Reduce CPU usage and connection improvements Drop g_ioService to avoid doing work during polling and make the thread sleep a bit if no message ready * Disable Emscripten's text decoder emscripten-core/emscripten#18034 * Basic mobile support - Handle touch events and longpress for right click - Check user agent to determine isMobile - Use VirtualKeyboardAPI to show keyboard (iOS not supported https://developer.mozilla.org/en-US/docs/Web/API/VirtualKeyboard_API) * Improve performance Drop manually swapping buffers to reduce CPU overhead * Case insensitive FS and properly return if websocket fails to be created * Fix Vorbis Linking (7cd3c82) * Allow gameWorld port to be set without rebuilding As servers and login servers are not adapted to send correct information when using the web client, it's necessary to override the world port and ip address that is received. Before, the world port was being forced to what was defined in the WEBPORT variable, not matter what port was informed when connect() was called. Now, you can override the port using lua (characterlist.lua) and avoid rebuilding the client. OBS: Port 7172 will still be overriden to 443 by the client. * Remove unused definition * Remove '&' mehah#894 (comment) * Remove swapBuffers call, we no longer use it mehah@3c6bc5a * Properly encode json mehah#894 (comment) * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/net/webconnection.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * Update src/framework/platform/browserplatform.cpp Co-authored-by: divinity76 <divinity76@gmail.com> * c++17 remove file * Recommended improvements mehah#894 (comment) mehah#894 (comment) mehah#894 (comment) mehah#894 (comment) * Remove uneeded link libs * remove regex * Cleanup shell.html * Make compiling easier - We can now use vcpkg.json with an adapted cmake command (check guide) - Update overlay-ports to the current baseline * Add baseline to overlay-ports vcpkg.json files * Workflows: ignore overlay-ports vcpkg.json * Bot V8 basic fixes Adapt load() calls to lua 5.1 * Disable UIGraph while the browser building issue is not found * Fix broken regex * Fix broken regex * Fix compiling after include changes --------- Co-authored-by: Ivan Clementino <ivancarlos.clementino@gmail.com> Co-authored-by: Renato Machado <mehahx@gmail.com> Co-authored-by: Rodrigo Paixão <god.rodrigo@hotmail.com> Co-authored-by: Luan Luciano <luanluciano@outlook.com> Co-authored-by: divinity76 <divinity76@gmail.com>
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.
The text was updated successfully, but these errors were encountered: