Error loading pointcloud tiles on WebGL: Uncaught RuntimeError: memory access out of bounds

[Cydra]

What happened?

With 1.20 we got experimental WebGL support. Works great for Worldterrain and OSM buildings, but tilesets with pointclouds are not loading, because of a runtime error:

Uncaught RuntimeError: memory access out of bounds

We encountered this with our own dataset, but it can be easily reproduced with the sample project.

Environment

Cesium For Unity Version: 1.20
Unity Editor Version: 6.0.58f2 (Used to open cesium samples)
Operation System: Windows 11 with RTX2070 Super
Can the issue be reproduced with cesium samples: Yes
When does the issue occur: Building the point cloud sample for the web platform and running in Chrome
Renderpipeline: URP-HighFidelity
Stacktrace: Stacktrace.txt

Reproduction steps

1. Open the cesium samples project
2. Configure the build:
   2.1 Set target to WebGL
   2.2 Set 06_CesiumPointClouds as the only scene for the build
   2.3 In the WebGL playersettings, set "Enable Native C/C++ Multithreading" to true
   2.4 Optional: Enable debug settings

• Enable development build
• Set Enable Exceptions to "Full With Stacktrace"
• Enable debug symbols

3. Built the WebGL application
4. Use a HTTP server which supports both COOP and COEP, which is required for multithreading. Built and run does not work.
5. Load the website and wait for the scene to load
6. The application encountered a runtime error: Uncaught RuntimeError: memory access out of bounds

Supporting evidence

No response

[Kevante]

I have a similar issue, with a slightly different error. Please let me know if I should open a separate issue:

What Happened?

WebGL build throws error and crashes while Cesium is loading in scene.

Environment

Cesium for Unity version: 1.20
Unity Editor Version: 6.0.58f2
Operating System: Windows 11

Reproduction steps

1. Open Project, which contains Cesium in one of the scenes
2. Configure Build

• Player Settings->Publisher settings->"Enable Native C/C++ Multithreading" = true
• Set Platform to WebGL
• Development Build
• Choose either "Build and Run" or build the start server with headers to allow multithreading
• Error occurs as soon as scene and Cesium are loading

Supporting evidence

CesiumWebGL.framework.js4514 TypeEr.txt

[brendan-duncan]

This is usually because Cesium is trying to use more memory than the maximum for the web build. You can increase the max memory limit in the Unity web player settings. It defaults to 2GB, but you can increase it to 4GB.

[Cydra]

I do not think this is the issue here, we already bumped the memory limit to 4GB in our own project and our test dataset is ~55MB in size.

[brendan-duncan]

Oh, I see it now, "ArrayBufferView value must not be shared". There's a call to UnityTransport, which looks like is setting up a WebSocket. It's complaining that the memory is pointing to a SharedArrayBuffer, which the browser isn't allowing.

This is an issue with multithreaded WebAssembly and the UnityTransport package you're using, not specifically with Cesium. It's unfortunate that to use Cesium we have to use multithreaded Wasm, and that multithreaded Wasm has so many security constraints that make it a pain. But without multithreading, Cesium would be much slower.

I can help look into if there's a work-around for this, I haven't used the UnityTransport package myself to know how it's getting that memory pointer.

The technical details are:
WebAssembly normally uses an ArrayBuffer for allocated memory. To enable multithreading, WebAssembly uses a SharedArrayBuffer instead. This is a type of ArrayBuffer that can be shared across worker threads. SharedArrayBuffer's have a lot of security restrictions, to protect against a type of browser exploits called Meltdown and Spectre (https://meltdownattack.com/). This was a big security hole in browsers and they had to put up a lot of protections against it, which makes things a lot harder to actually use.

One of these security protections is that not all APIs allow SharedArrayBuffers to be used. It seems the Emscripten (the compiler used to compile to WebAssembly) UTP WebSocket library is one that does not allow SharedArrayBuffers to be directly used. This would likely make it too vulnerable to security problems.

Sow how does one get around issues like this? A regular ArrayBuffer must be used instead of a SharedArrayBuffer. How can that be done? That's what needs to be investigated, I don't know for this function currently.

[brendan-duncan]

I'm looking at the UnityTransport code now. I'll tell the authors they need to make js_html_utpWebSocketCreate aware of SharedArrayBuffer. It should be an easy one-liner fix in the UnityTransport code. They just weren't aware of it because multithreaded Wasm is relatively new.

In the meantime, I'll see if there's a local patch you could do to get unstuck while waiting for an official fix in UnityTransport.

[brendan-duncan]

While I submit a proposed solution to the UnityTransport team, here is a quick hack work-around.

Download this file, remove the .txt extension (github didn't let me attach it otherwise) so the filename is patch_unity_transport.jspre, and copy it to your Unity project Assets. It's a javascript plugin that will overwrite the native JS functions used by UnityTransport and replace them with versions that will automatically convert any SharedArrayBuffer memory to a regular ArrayBuffer so that the functions work properly.

patch_unity_transport.jspre.txt

[brendan-duncan]

Also, there are two issues in this thread now. The original error from @Cydra is an out of memory error. The error from @Kevante is the UnityTransport thing I've just been going on about. I should have noticed and clarified that earlier.

[Kevante]

Quick Update:

• I was able to solve the SharedArrayBuffer error using the fix provided by @brendan-duncan (Thanks!)
• Upon connecting as a client to a networked room hosted by another machine, I am now either getting an error for exhausted thread pool, or being disconnected by Unity Netcode For GameObjects by the Server for timing out.
• I have been attempting numerous methods to increase the ThreadPoolSize in the WebGL build, most recently by creating a dummy WebGL build, which generates the emscripten .rsp files, and then patching them with an increased THREAD_POOL_SIZE= argument.

Currently, I'm still debugging this final step, but aside from being disconnected, the errors I receive are thread related, including one from Cesium. While debugging, I am currently disabling the CesiumTilesets, and just attempting to debug the thread pool issue

[brendan-duncan]

Here's a secret Unity devs don't want you to know (joking, I want you to know :-)) :
You can add Emscripten args to the project by opening ProjectSettings/ProjectSettings.asset in a text editor (it's just a yaml file), search for webGLEmscriptenArgs, and add flags for emscripten there.

webGLEmscriptenArgs: -sPTHREAD_POOL_SIZE=20

[Kevante]

Update:

After extensive testing, I have been able to pinpoint the issue to multithreading + NGO causing an instant disconnect. I completely removed Cesium from my build and began joining a networked room hosted by a windows build running on a different machine. When Native C++ multithreading is disabled in the project settings, we are able to join the room from the WebGL client when using a regular http server, as well as a threaded server. When multithreading is enabled, we join the room and then instantly disconnect. The disconnect is instant, regardless of heartbeat/timeout time. After applying the patch @brendan-duncan supplied, as well increasing the thread pool size (also thanks to Brendan!), I no longer get errors. I'm unsure if it's something I'm doing, the copied data is somehow different, or if something is failing silently in NGO when multithreaded.

Reproduction steps:

1. Enable Native C++ multithreading, have patch_unity_transport file (WebGL enabled), Developer Build
2. Host server with threading headers
3. Launch WebGL build and attempt to join room (empty scene) as client (via NGO)

Notes:

• Attempted adjusting timeout times to 10-15 seconds, but client still disconnects immediately
• The host does not register the client disconnect until the timeout time has elapsed (timeout message 10-15 seconds after disconnect takes place on client)
• Tested on empty scene as well as normal production scene
• Everything works if Native C++ multithreading is disabled
• This is using latest NGO 2.8.0

Supporting Evidence:

Logs:

Settings:

Outcomes:

[brendan-duncan]

I suspect like the transport package that something in NGO doesn't like SharedArrayBuffers. I'll take a look at that package when I get a chance soon.