Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Bug] UTF8 decoder fail to decode a byte array in a WASM app on combo Android ARM + Chrome + AOT #106755

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dbriard opened this issue Aug 21, 2024 · 11 comments
Assignees
Labels
arch-wasm WebAssembly architecture area-System.Text.Encoding needs-author-action An issue or pull request that requires more info or actions from the author. no-recent-activity os-android Priority:3 Work that is nice to have
Milestone

Comments

@dbriard
Copy link

dbriard commented Aug 21, 2024

Description

Hi all,
I discoved a strange issue in .NET8.
I have a WASM application build using Avalonia framework that was running fine on my platforms (desktop browsers, and android browsers).
After I migrated from .NET7 to .NET8, the "website" failed to load on my Android device throwning a exception.

I debugged as deep as I could and found that the problem come from the GetChars function in Encoding.UTF8.GetDecoder().

The function is used by ReadString() of BinaryReader.

Here my debug output on platforms that works:
image

And here is the same on my android phone using Chrome latest version.
image

The 15 first characters are not read correctly! I read severals strings, and for each strings the first 15 characters are 0.

What is really strange, is that on the same device, there is no problem when I run the website on Edge browser. Same issue on a different phone.

Here more tests:

Android device 1/Chrome => BUG
Android device 2/Chrome => BUG
Android device 1/Chrome BETA => BUG
Android simulator on Windows 11/Chrome => work
Android device 1/Edge => work
Windows11/Edge => work
Windows11/Firefox => work
Windows11/Chrome => work

My code is compiled using AOT.

Reproduction Steps

Try to decode the following byte array on a WASM app (AOT?) on Android physical device in Chrome browser.

image

Expected behavior

The result should be:

image

Actual behavior

The 15 first chars are 0 on android device using chrome.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

I cannot debug more deeper as the code is not accessible:
image

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 21, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Aug 21, 2024
@dbriard dbriard changed the title [Bug] UTF8 decoder fail to decode a byte array in a WASM app on Android and Chrome browser [Bug] UTF8 decoder fail to decode a byte array in a WASM app on combo Android ARM + Chrome + AOT Aug 21, 2024
@dbriard
Copy link
Author

dbriard commented Aug 21, 2024

Additional details:

I tried without AOT compilation and the problem do not happen.
So far, GetChars only fail on .NET8 + Android real device + Chrome + AOT compilation.

I also tested on Firefox android, no problem, and on iPhone (Safari and Chrome), no problem...

So in the end, not sure if the issue is in .NET8 or Chrome ARM on android...

If you need additionnal info, let me know.

@jeffschwMSFT jeffschwMSFT added the arch-wasm WebAssembly architecture label Aug 22, 2024
Copy link
Contributor

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-globalization
See info in area-owners.md if you want to be subscribed.

@jkotas jkotas added area-System.Text.Encoding and removed area-System.Globalization needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 22, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-text-encoding
See info in area-owners.md if you want to be subscribed.

Copy link
Contributor

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

@tarekgh
Copy link
Member

tarekgh commented Aug 25, 2024

CC @lewing

@ilonatommy ilonatommy added this to the 10.0.0 milestone Aug 26, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Aug 26, 2024
@lewing
Copy link
Member

lewing commented Sep 26, 2024

I think this is probabaly a chrome issue where there is a bug when running wasm on a 32bit build, Chrome on android is shipped as a 32 bit executable by default. All the scenarios where chrome works are 64 bit builds.

@kg what is the best way to file issues like this?

@lewing lewing assigned ilonatommy and unassigned mkhamoyan Sep 26, 2024
@danroth27 danroth27 added the Priority:3 Work that is nice to have label Jan 13, 2025
@ilonatommy
Copy link
Member

ilonatommy commented Apr 4, 2025

Other information

I cannot debug more deeper as the code is not accessible: image

@dbriard, I don't have a setup for direct reproduction of this but for now, let's focus on this point. The line is here:

You could build the runtime repository from source, if you have never done it, the instructions are here.

Then, in your client project replace the runtime used by the application by adding:

<Target Name="UpdateRuntimePack" AfterTargets="ResolveFrameworkReferences">
   <ItemGroup> <ResolvedRuntimePack PackageDirectory="C:\Users\user\source\repos\runtime-fork\artifacts\bin\microsoft.netcore.app.runtime.browser-wasm\Debug" Condition="'%(ResolvedRuntimePack.FrameworkName)' == 'Microsoft.NETCore.App'" />
   </ItemGroup>
</Target>

Let me know if you can step in after this operation and if there's any more hints on what's going on.

Edit:
Apart from that, have you ever tried non-AOT? Is the result different for the 1-3 cases for your list?

@lewing
Copy link
Member

lewing commented Apr 18, 2025

Given that it is the first 128bits that are zero, can you also try building with
<WasmEnableSIMD>false</WasmEnableSIMD> I suspect this may be a chrome arm simd bug.

@lewing lewing added the needs-author-action An issue or pull request that requires more info or actions from the author. label Apr 18, 2025
Copy link
Contributor

This issue has been marked needs-author-action and may be missing some important information.

Copy link
Contributor

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly architecture area-System.Text.Encoding needs-author-action An issue or pull request that requires more info or actions from the author. no-recent-activity os-android Priority:3 Work that is nice to have
Projects
None yet
Development

No branches or pull requests

9 participants