WebGL - RuntimeError: memory access out of bounds

I'm seeing frequent exceptions from Unity's main rendering loop in WASM-compiled WebGL players. I'm using Unity 2020.1. I'll create a support ticket but I want to get this information out there for other developers who may be impacted.

Behavior: Unity's WebGL player will randomly crash the WASM runtime with a fatal "memory access out of bounds" error. It doesn't happen in the editor or PC/Desktop builds. The stacktrace shows it is internal to a material pass and render.

ApplyMaterialPassAndKeywordsWithCache

I suspect the issue can be remedied by turning off dynamic batching. Will try and report back here.

 

Did you found any solution for this?

 

Partially. See https://forum.unity.com/threads/async-await-and-webgl-builds.472994/page-2#post-6218307 for a few suggestions which may help. I am unable to eliminate all threading issues. WebGL threading, whether in C# or Unity itself, is very broken.

Recent issues...
- Builds broken - https://forum.unity.com/threads/can...settings-webgl-threadssupport-is-true.952772/
- Concurrent collections unsupported - 1243361 (Open) WebGL Blows up on ConcurrentDictionary.Count

Does anyone know the bug id for general threading being broken/unsupported in C# user code?

 

@jukka_j I am only now starting to appreciate the full impact and scope of the statement, "multithreaded C# is currently not supported even with multithreaded Unity WebGL builds".

There are quite a few third-party assets in the store which provide support for WebGL. Many of these assets are highly rated and widely used. @BestHTTP and UniTask comes to mind... These assets use ConcurrentDictionary. As I understand it, ConcurrentDictionary is unsupported in WebGL (see https://fogbugz.unity3d.com/default.asp?1243361_i2ujptm2ut9qhjai) due to it being considered "multithreaded C#". This is a genuine land mine for compatibility issues! The compiler does not flag use of these classes and the only hint that something is wrong are random out of bounds memory errors that crash the compiled Unity WebGL player. Developers beware!

*Updated to note that BestHTTP uses its own implementation of concurrent classes (not ConcurrentDictionary). As a result, BestHTTP is stable in WebGL builds (source developer).

 

@stonstad : That's a major hint for a lot of WebGL developers here I'm sure! You have to be extra careful with plugins with WebGL to avoid dependencies like that one that'll cause head-scratching bugs down the line.

 

I'm working to provide a reproduction project. Reproducing threaded and/or random errors can be very challenging.

 

When we say C# user threading is unsupported it would help to know what this includes. A list would be helpful for us @jukka_j.

Supported

• Async / Await (without threading)
• Lock
• Mutex
• Interlocked

Unsupported:

• ConcurrentDictionary
• ConcurrentQueue
• Thread / ThreadStart / ParameterizedThreadStart
• Task.Run
• ThreadPool
• Timer (System.Timers.Timer and System.Threading.Timer).

Updated 10/6/2020 (Unity 2020.1.6f)

 

I updated the above list. I am wondering if certain timer classes are unsupported?

 

System.Threading.Timer uses ThreadPool threads. System.Timers.Timer uses System.Threading.Timer. I'll update the list above.

 

@jukka_j OK, I included a reproduction project for random freezes that are happening without an error or stack trace. WebGL Player Freezes (Bug Case 1283169). I wanted to make it as small as possible, and highly repeatable. The best case scenario for causing a freeze is to load the same WebGL player project in two browser tabs at the same time.

 

Thanks, @jukka_j . Resubmitted through Unity w/ Case #1283357

 

The Unity documentation should be updated to reflect which .NET APIs are unsupported in the WebGL player. I understand the breakage might be temporary but a fix doesn't seem likely anytime soon.