WebAssembly compilation fallback logic is wrong. May need some further docs about configuring memory limits.

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I developed my own PWA application using Blazor. The app works normally on my computer and phone. But on my second phone the application doesn’t have time to load and an error appears. I connected my phone to the pc and through the chrome devtools I went to see the log on the console and I found the following errors.

Streaming compilation failed. Falling back to ArrayBuffer instantiation.  RangeError: WebAssembly.instantiate(): Out of memory: wasm memory

blazor.webassembly.js:1 TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
(anonymous)	@	blazor.webassembly.js:1
(anonymous)	@	blazor.webassembly.js:1
await in (anonymous) (async)		
(anonymous)	@	blazor.webassembly.js:1
createWasm	@	dotnet.6.0.2.hy3rmx5lfa.js:1
(anonymous)	@	dotnet.6.0.2.hy3rmx5lfa.js:1

blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to execute 'arrayBuffer' on 'Response': body stream already read
    at blazor.webassembly.js:1:36928
    at async blazor.webassembly.js:1:36900
    at async blazor.webassembly.js:1:36636
(anonymous)	@	blazor.webassembly.js:1
await in (anonymous) (async)		
(anonymous)	@	blazor.webassembly.js:1
createWasm	@	dotnet.6.0.2.hy3rmx5lfa.js:1
(anonymous)	@	dotnet.6.0.2.hy3rmx5lfa.js:1

The PWA is distributed as AzureStaticApps. Some specifics about the phone having these problems:

• Phone model: Samsung Galaxy J5 (2016)
• Android version: 7.1.1
• Chrome version: 98.0.3758.87
• Edge version: 97.0.1702.78

I attach some photos of the console and network traffic

Expected Behavior

The PWA should work just as well as it does on the PC and other phones

Steps To Reproduce

Simply, create a PWA project and try it out on low-end phones.

Exceptions (if any)

No response

.NET Version

6.0.102

Anything else?

No response

[StephenEhlers]

I discovered that my production deployment was using about 8x more memory than my local development instance for a total of 512MB, now add on top of this the refresh memory leak and it causes devices to go over 1GB.

Testing locally out of my visual studio debugger I could not reproduce the memory issue. So I set up a local IIS server and deployed to it with a local file publish process. With this IIS instance I was able to reproduce the 500MB issue. I then compared the output of the visual studio debug instance to the IIS published instance. I found that the generated _framework/dotnet.6.0.x.js files were substantially different and there the root of my problem:

looking into this INITIAL_MEMORY property I found some github forum posts saying that for Development environments it will default to 16777216 (16MB) and Production environments will default to 536870912 (512MB). Normally this is not a huge deal but with the Memory Leak in .NET 6 and chrome after refresh it is a major problem.

In C:\Program Files\dotnet\packs\Microsoft.NET.Runtime.WebAssembly.Sdk\6.0.4\Sdk\WasmApp.targets it says the following in the documentation section:

Knowing this, I then tried adding the referenced EmccTotalMemory property to my Blazor.Client csproject file.

<PropertyGroup> <TargetFramework>net6.0</TargetFramework> <EmccTotalMemory>16777216</EmccTotalMemory> </PropertyGroup>

I rebuilt and published to my local IIS site and thankfully the 512MB was now down to ~50MB. I then published to a public test instance and re-tested all of my failing devices and they are now all working great, even with the refresh memory leak because it goes from 50-60MB to 120MB instead of 512MB to 1GB.

@SteveSandersonMS For me anyway the priority of fixing this Refresh Memory Leak is reduced as I found the workaround to reduce total inital memory, but I feel it is still important to fix this sooner than later. This could be causing lots of random issues during app use, granted mostly for low end devices, but this is quite a bit of a difference from the total memory use of the same app running on .NET 5.

Additionally, I do not like the logic behind having 16MB for Development builds and 512MB as the initial memory size for Production. I get that you may want development instances to show “True Memory Usage” so it starts small and then auto expands to what it needs so Devs can more easily see what their app is utilizing. And I get that allocating memory on the fly might result in poorer performance, so for Production builds it auto allocates 512MB. However, to me this falls into the category of pre-optimization. I would rather that both my Development and Production instances behaved the same for memory allocation until I choose to optimize it. This difference in behavior caused a problem to only represent in a production instance with no natural way to diagnose it in a dev environment without tearing apart the OOB Microsoft publish process.

Anyway sorry for the book and hopefully if anyone else is running into this they can take the same steps as me to work around it for now.

[SteveSandersonMS]

@TanayParikh Thanks for confirming.

@mkArtakMSFT I’ve updated this issue title to reflect our newer understanding. This is something we should try to address in .NET 7 if we can, as it’s relatively cheap (~2 days I’d guess).