Webassembly AOT Crashes Android Mobile (v96) #62149
Comments
|
@legistek my comment that you've linked was related to an issue with a Blazor app running in the interpreted mode, which had been fixed by Google (at least for the time being). You may be experiencing a different problem. |
|
Ohh, thanks @daniel-p-tech sorry I missed that detail. Could be a different issue then. I will confess I'm doing some, let's say, unconventional stuff with WASM-Javascript interop. But, since everything works fine in interpreted mode and AOT in Windows Chrome, it seems reasonably likely that it's not anything I'm doing wrong and that this is affecting other people/applications. |
|
Can you please create a new project, publish with AOT and try to run on the same device and see whether you hit that issue or not? |
|
Hi @legistek. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
|
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate. See our Issue Management Policies for more information. |
|
I will get you an answer shortly. Please don't close it. Thanks. |
|
Ok, so not surprisingly, just compiling the default project with AOT and publishing it on a server works fine with my Android Pixel. I definitely want to try to do what I can do diagnose this, but I'm going to need a little bit of help/guidance. After all, publishing AOT is pretty slow, so trying to find the exact thing in my code that causes it is going to be excrutiatingly difficult without some guidance. So the question is what sorts of things could possibly be different between AOT and interpreted that could cause the browser to totally crash in one and not the other? As I mentioned I am pushing the envelope a bit. For example I'm using some of the low-level JS interop (the same things that Blazor itself uses), such as providing a custom argument signature to But this bears repeating:
There must be a finite number of things it could be. Any suggestions of things to try to diagnose this would be welcome! Thanks! |
|
I managed to do a remote debug on my phone and see this in the browser console: Streaming compilation failed. Falling back to ArrayBuffer instantiation. RangeError: WebAssembly.instantiate(): Out of memory: wasm memory Hope that means something? |
|
I can also confirm that my |
|
I found this related issue and so added this to my WASM project's CSPROJ to reduce the initial memory allocation: Now instead I get this console error: |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
dotnet-issue-labeler
bot
added
the
untriaged
|
@lewing can you guys please look into this? Thanks! |
|
Just a little more information that may help: I tried a second project that shares a lot of the code with the first one, but is quite a bit smaller. This one originally crashed with the same issue, prior to me using the Once I added My main project, however, crashes no matter what memory setting I used. (Well, I've tried 128MB and 256MB). It does seem likely that the Perhaps someone close to that issue could provide some tips on how to set it properly? Or is there any way of knowing how much memory a particular Chrome version will allow for the array buffer on a particular device? Thanks! |
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsHi, unfortunately this closed issue seems to have re-emerged. AOT .NET6 works perfectly in Chrome on Windows but on mobile Android the Webassembly piece starts to load, then gives the "Aw Snap" reload screen of death. Also works perfectly on mobile Chrome when using interpreted mode so this is limited to AOT on Chrome Mobile. Other info: My co-worker had the same problem on his Pixel 5, but NOT when using the Adblock browser - only Chrome. I'm afraid I'm not in a position to post code and have not found the minimal reproducible steps yet. I'm hoping someone might understand the basics of what might be going on sufficiently to suggest some diagnostic steps. BTW, it took me awhile to get around to upgrading to NET6 to try AOT but it's really fantastic. My application is MUCH MUCH faster across the board and honestly the file sizes and startup times aren't any worse than our legacy Angular app primarily because our main JS payload is so much smaller now. So I really think AOT will be important for mobile devices and will do what I can to assist in finding a solution to this. Originally posted by @danroth27 in dotnet/aspnetcore#33559 (comment)
|
|
cc @radekdoulik |
|
Hi all - I realize it may be awhile before anyone can turn to this, but I figured I'd offer this update - My application works fine, AOT or interpreted, on a new iPad. Thus, so far, the only issue is AOT on Android. |
|
I am experiencing the same issue with several browsers on Android: Chrome, Firefox, and DuckDuckGo. Either the page is stuck in "Loading..." mode (Firefox and DuckDuckGo) or Chrome shows the "Aw, Snap!" error page. This only occurs when I enable AOT compilation. Everything works fine after disabling AOT compilation and republishing/redeploying. |
|
Sorry for your trouble but glad to know it's not just me. Is anyone on the Blazor team able to look into this? Unfortunately it makes AOT unusable for us. |
|
i need this to be fixed asap tbh. I bet on blazor and my app is running on >100 Android Devices, now without AOT. My client reported me already about the performance decrease. Hope to get any fix asap. |
|
It sounds like the apps are hitting chrome android wasm memory limits when aot compiled. Since this is likely application specific we'd need a way to reproduce the error to even begin to understand why. |
|
My application is open source. Feel free to compile and run it. When I run the app locally using |
Do we have any way of knowing what those are? Do they vary by device?
The "why" is the applications are complex. Since they work perfectly in interpreted mode and other devices this is plainly not an issue with our code. If we have to keep our app sizes low to avoid crashing, then we need some way of knowing what the size limits are. |
|
Also just to be clear, whether it crashes is based solely on the size of the executables and not any memory allocation done by our applications. I know because my application's WASM never actually gets invoked (I have console.logs etc. to trigger when main() is executed). |
|
can you please attach the output of chrome://version from a failing device |
|
Of course. Hope this helps. |
|
I think @legistek is on the right track with large file sizes being the problem. As I recall when testing, Chrome reported there was only 10-12 MB worth of stuff in the browser cache after a crash occurred. |
|
does the app work in edge on android? |
I didn't know there was such a thing. ;) I'll try it out. Like Jack I gave up on AOT awhile ago so will have to rebuild. |
edge is chromium based but there is an important difference that suspect is the cause of the problem here |
|
AOT seems to work fine in Edge for Android. Man I forgot how much faster it was; would really be great if this could be sorted out. Just for kicks I tried it again in Chrome Android and this time - for the first time - I was able to get the app running for awhile before I got "Aw Snap". But I did get "Aw Snap" eventually. I must be at the borderline of RAM usage? |
|
The behavior you are experiencing is due to a 32bit build of Chrome and the resulting lack of address space. The issue and the comment here WebAssembly/design#1397 (comment) describe the situation. Edge on android is a 64bit build so it doesn't have the same issue. We're discussing if there anything we can do on the runtime side to make the problem less acute. |
|
Whoa, that issue comment you linked to seems to be saying WASM across the board is not suitable for mobile devices. Why doesn't this happen in interpreted mode? And should we expect it will if the application gets complex enough? |
This causes TurboFan compilation on android chrome to fail, showing the "aw, snap" error. The issue is absent in android Firefox. Strangely, the issue is also not present in some other chromium browsers (android edge, opera), which leads to possibly the main relevant issues: dotnet/runtime#62149 WebAssembly/design#1397 (comment)
|
Also hitting this - my .Net 7-preview-7 app runs fine on Android unless I enable AOT compilation, at which point it breaks (never gets to the point of executing any code in Program.cs in WASM). This is running on Android 12, Chrome 105. It runs fine in Edge. According to the earlier comment, the issue is a lack of 64-bit Chrome, because that isn't available for devices with less than 8GB. I'm running this on an S21FE which has 8GB.... Looking forward to seeing what can be done to make this a) work and b) easier to debug. |
I imagine if Microsoft ever decided to port its Office apps to Blazor it would be addressed REAL fast. Until then there doesn't seem to be much attention being placed on mobile device compatibility. |
|
Problem with Chrome Android still persists in .NET 7.0.100-rc.1 preview.
|
|
A pretty straightforward work-around is to host a separate, non-AOT compiled version of your application for mobile browsers. Feel free to use the Nginx configurations I am making available in the pull request linked above (or here). The redirect criteria were pulled from http://detectmobilebrowsers.com/ |
|
We are also experiencing this issue:
Hosting a non-AOT version for mobile is no option. The performance gain is crucial even more for mobile devices. |
That would be probably hotfixed by #80849 for next Net7 service release.
Large projects produce large AOT images. |
Hi, unfortunately this closed issue seems to have re-emerged.
AOT .NET6 works perfectly in Chrome on Windows but on mobile Android the Webassembly piece starts to load, then gives the "Aw Snap" reload screen of death. Also works perfectly on mobile Chrome when using interpreted mode so this is limited to AOT on Chrome Mobile.
Other info:
Chrome 96.0.4664.45
Android 11
Pixel 4 XL Build RQ3A.210905.001
My co-worker had the same problem on his Pixel 5, but NOT when using the Adblock browser - only Chrome.
I'm afraid I'm not in a position to post code and have not found the minimal reproducible steps yet. I'm hoping someone might understand the basics of what might be going on sufficiently to suggest some diagnostic steps.
BTW, it took me awhile to get around to upgrading to NET6 to try AOT but it's really fantastic. My application is MUCH MUCH faster across the board and honestly the file sizes and startup times aren't any worse than our legacy Angular app primarily because our main JS payload is so much smaller now.
So I really think AOT will be important for mobile devices and will do what I can to assist in finding a solution to this.
Originally posted by @danroth27 in dotnet/aspnetcore#33559 (comment)
The text was updated successfully, but these errors were encountered: