Search Issue Tracker
By Design
Votes
0
Found in
2022.3.63f1
6000.0.51f1
6000.1.7f1
6000.2.0b6
6000.3.0a1
Issue ID
UUM-109244
Regression
No
Crash/Memory leak in a WebGL build when executing a very large switch statement multiple times
Reproduction steps:
1. Open the attached project ("100067_Repro")
2. Build and Run the project for WebGL
3. In the build, press the "Large switch" button
Expected result: The build continuously runs the switch statement every frame
Actual result: The build browser tab crashes after a few seconds
Reproducible with: 2022.3.63f1, 6000.0.51f1, 6000.1.7f1, 6000.2.0b6
Reproducible on: Windows 11 (User), MacOS 15.5 (Intel)
Not reproducible on: No other environment tested
Notes:
1. The build works without issues if every case in the switch statement is split into its own method. This can be tested by pressing the "Large switch func" button instead of the "Large switch" one
2. The memory leak/crash does not occur in the Editor
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- var VisionOSEDRHeadromm has a comma instead of a dot when building with Metal Rendering App Mode and local OS localization is set to German
- IAP Catalog remove product “x” and add product “+” buttons are not consistent with other remove and add buttons in the Editor
- Performance issues in Play Mode when quickly hovering the mouse cursor over Hierarchy GameObjects
- Frame Debugger displays incorrect output when FidelityFX Super Resolution or Spatial-Temporal Upscaler is used with Temporal Anti-aliasing or Subpixel Morphological Anti-aliasing
- The layout system is failing to correctly calculate or apply the height of the Japanese fallback font when the primary English font's metrics are used
Resolution Note:
The cause of the crash is that the WebAssembly stack is exhausted by the user code which causes the out-of-memory crash in some browsers(we noticed that this only seems to affect Chromium-based browsers).
The crash is not reproducible on other platforms because of different sizes of the stack and different scripting backends.
There are some ways to workaround this issue:
* Increase the size of the WebAssembly stack by creating an editor script that sets`PlayerSettings.WebGL.emscriptenArgs = “-sSTACK_SIZE=2048kB”;`(Or a higher number as seen necessary). Alternatively, the file ‘ProjectSettings\ProjectSettings.asset’ can be edited by hand and the setting can be added to the field ‘webGLEmscriptenArgs`.
* Refactor the code to split up the large factory method into multiple functions(as done in the bug project with “large switch func”)
* Store the information for the different Mahjong fields in files instead, e.g., a json file, and load the files on demand in the factory method.