Bug Android Chromium - Unable To Grow Allocated Memory Above 256MB [Confirmed]

Hey everyone,

Our team put together a WebGL memory stress test. You can enter the number of textures to load and press the button to load them. It displays the available memory information we have access to for the platform.
https://brandxr-discovery.s3.amazonaws.com/WebGL/MemoryStressTestWebGL/index.html

Here are my findings...

Windows 10 PC

• Chrome - 1.96GB
• Edge - 1.95GB
• Firefox - 1.96GB

Android [Galaxy S20+]

• Chrome Beta - 219MB
• Chrome - 219MB
• Ecosia - 219MB
• Firefox - 1.96GB
• Samsung Internet - 219MB
• Opera - 219MB
• Edge - 1.93GB

Android [ Galaxy S9]

• Chrome - 219mb

iOS [iPhone SE 2020]

• Safari - 426mb
• Chrome - 426mb
• Edge - 426mb
• XRViewer -- 426mb

iOS [iPhone 11 Pro Max]

• Safari - 442mb

iOS [iPhone 8]

• Safari - 210mb

iOS [iPhone 6]

• Safari - Fails to open (out of memory)

You can see in my findings that on mobile Android Chrome-based web browsers are unable to increase the size of the memory used by WebGL.

For the iPhone SE 2020, that device only has 2GB of RAM to start with, so it's no surprise we can't get to the 2GB limit. Weird that we're only able to get to around 426mb, I wonder how that was determined (maybe we can't go larger than 480mb of allocated memory in the heap?).

The iPhone 6 only has 1GB of memory to start with. I'm going to try making a build with 128mb initial memory and see if WebGL runs on that device. [Update: nope!]

This build was made with brotli compression, high code stripping, and WebGL 1.0 via Unity 2020.1.4f1.

I've read that by default WebGL will increase the size of the heap in 32mb blocks, with 256mb allocated at the start.

Anyone got any ideas on things I should try? Can anyone else share the results of the test from their devices?

 

So I made a new build with 128mb memory to start, and used Chrome dev tools to view the console to see what kind of error feedback I could get on Android Chrome. But the actual error message isn't any different then what I would expect [Could not allocate memory].



Weirdly, the crash still happens when growing the memory above 256mb, it gets past 128mb perfectly fine.

For my next test, I'm going to try to make a build that starts at 512mb allocated, and see what happens on Android Chrome in that scenario.

 

Well, I made a build that defaults to 512mb, but it still crashes when getting to the same 256mb limit.

This tells me that the PlayerSettings.WebGL.memorySize doesn't do what I thought it does. And yep, looking it up this value has been deprecated and doesn't do anything on Web Assembly builds. Doh!

I'm going to continue researching what else can be done about this, having a hard limit of 256mb on mobile Chrome is pretty bad!

 

So I made some new builds using PlayerSettings.WebGL.emscriptenArgs to set the initial memory.

128MB Initial
512MB Initial

So on Android Chrome, the 128MB build works fine until the memory reaches 256MB, and then gives the [Could Not Allocate] error in the console.

On the 512MB build, I'm able to add images until I get near 512MB, and then the app crashes with the [Could Not Allocate] error in the console.

So, this does show an actual bug! At least I know I'm not crazy. Next step is to figure out the best developers to report this to from the Unity team and file a bug report.

 

Submitted a bug report to the Unity tracker.
#1296850_jo7dcmobll7c762m

 

That might also be emscripten or SDL2 emscripten bug
https://github.com/emscripten-core/emscripten
https://github.com/emscripten-ports/SDL2

(And you might want to edit your bug report message to include only the bug number, and not your private link)

 

So for anyone wondering how to work around this issue, what our team is planning on doing is making multiple WebGL builds with different initial heap values { 64, 128, 256, 512, 1024, 2048 }, and then loading only that version and not allowing our application to go above the initial value (by using assets with different levels of detail and memory required).

Then when a memory crash occurs, we will log how much memory we initialized with, and then the next time that device loads our app, we'll choose the next lowest initial memory version. So at least there's a limited amount of crashes possible before we automatically start knowing how much memory can be requested.

We'll probably have to use a device detection API to figure out what device is actually attempting to load our app since there isn't an easy way to know this out of the box.

Yes, this is a major bug and annoying. But at least with a lot of elbow grease, we can work around it!

 

I've added the test project to a public Github for the Unity QA team and received word from them that they've at least seen the issue, no word on the timing for when this will be looked into yet, but I'm hoping sooner rather than later!

 

This bug is now officially listed in the Unity Issue Tracker. Make sure to vote for it to be worked on!

 

@jukka_j That's super-valuable to know. I'm going to have our dev team check if the browser is 32-bit, and then if it is we'll load a WebGL build that is initialized to 256mb, and only use assets that fit within that limitation with a buffer to prevent memory from growing. Hopefully, Google gets around to transitioning chromium-based browsers to 64-bit this year!

 

@jukka_j Just saw your Safari & Chrome bug reports, hopefully, we this gets the attention of the developers.

I tested your web assembly app on my Galaxy S20+, and it fails to grow the heap size beyond 501mb (unable to allocate 512mb). But no crash, so that's nice! Would it be possible to let Unity devs be aware of this memory growth failure via a callback?

 

Hi @jukka_j , I'm working with @DerrickBarra on this problem and was hoping you could share any insights on the following possible fixes:

1. We're trying to detect whether the user's browser is 32 or 64 bit but there doesn't seem to be a reliable way to do this. 32/64 bit Chrome can be detected via the user agent string, but otherwise the closest I've got is identifying whether the OS is 32/64 bit from the user agent string, using these strings: https://stackoverflow.com/a/13709431 but this doesn't help detect 32 bit browsers on 64 bit OS's.
   I was wondering if you know of a more reliable/foolproof way of detecting the browser type.
   
   
2. Specifically, the third solution proposed in the last comment in this thread:
   https://bugs.chromium.org/p/chromium/issues/detail?id=1175564
   
   Which suggests attempting to allocate WebAssembly.Memory in a loop, starting with the maximum memory and decreasing until it succeeds. If something like this could work, how can it be implemented? For instance, does it have to be part of the framework.js or could it be part of the template files somehow? Is this potentially a feature that we might see for WebGL in the future?
   

Thanks!

 

@jukka_j Just read your write up on the WebAssembly github, that was insightful to read, thanks!

I'm going to instruct our team to treat all mobile devices as having an upper limit of 256mb, and follow your progress on this issue via this thread. When I see other developers talking about this type of issue, I'll point them here so we can collectively follow the progress.

 

@jukka_j
Any idea when this fix will make it into the latest chromium/chrome web browsers on Android? I didn't see anywhere that mentioned what Android Chromium version will receive the patch or when.

From what I read, we should be able to rely on 32-bit Chromium Android browsers in the future being able to reserve up to 1gb of RAM.

Once this change rolls out, we'll change our memory logic to the following...

---------
Before Unity WebGL loads, store a variable in javascript called maxAvailableMemory.

- If [memory api] is not available, set our max available memory to 256mb.
- Else if [memory api] is available, and we detect [32-bit browser], ensure that the variable does not exceed 1024mb.
- Else if [memory api] is available, and we detect [64-bit browser] set to 2048mb (Unity WebGL's current limit).

Our Unity builds will use the default initial heap size and allow the Grow() command to work its magic. Then in our C#, we will make sure the assets we load for our project stay within the maxAvailableMemory we found earlier.
----------

Firefox and Safari desktop will be limited to 256mb max memory, because they lack the performance API to check memory availability. But I can't think of another way to prevent OOM crashes.

I saw your message to the Firefox team back in 2018 about adding the window.performance.memory to Firefox, shame it was never implemented. I saw they have the mozMemory, but according to this bugzilla thread, it's hidden behind a browser flag. I also didn't spot a Safari equivalent or polyfill for chrome's runtime memory api.

Alternatively, these types of issues could be solved by being able to respond to memory allocation errors at runtime.

Overall, this patch means we won't have to worry about building multiple Unity WebGL builds with different initial heap sizes. So that will be nice.

 

First of all, I just want to say how happy I am to have found this thread. Thank you for your contributions.

> Our Unity builds will use the default initial heap size and allow the Grow() command to work its magic. Then in our C#, we will make sure the assets we load for our project stay within the maxAvailableMemory we found earlier.

The C# workaround is the part I'm trying to develop now. Would you mind sharing what your strategy is? What kind of assets are you loading, and do you know their heap size ahead of time?

My workplace is developing a WebXR application with runtime model import, and it also hits this 256mb ceiling on Oculus Quest's browser, which is 32-bit Chromium Android. We are loading GLBs with GLTFast. The used & free managed heap size (GetMonoHeapSizeLong) grows wildly during the package's loading function ,but the used managed heap size (GetMonoUsedSizeLong) grows predictably during file load. This leads to the managed heap doubling at a time that I'm pretty sure we can't predict without modifying GLTFast's code. I was wondering if that's a dead-end for us for a solution similar to yours, or if you are measuring asset sizes on-the-fly.

I am willing to make another thread so we can stay on-topic on this one. (Again, I can't stress how much it's a relief to see this bug getting tracked here.)

 

@chibinhdang : For our project, we have all of our assets created with multiple LOD's, using Draco + KTX2. And all of our UI textures are in .basis

I wrote up a guide a little while back for my team to help our overall understanding of heap size requirements, good enough for estimates anyways. I'll make a new WebGL forum thread for the community.

Edit: Made the thread.