-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[browser] Enabling WasmStripILAfterAOT breaks app with 'NIY encountered' and results in larger build size #92238
Comments
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsDescriptionI've tried enabling recently added Reproduction Steps
Expected behaviorApp works as before and binaries size is at least not larger than before. Actual behaviorBinaries size is slightly larger (5.06MB on my end) and app crashes with the following log: Browser console log
Regression?No. Known WorkaroundsNone. Configuration.NET 8 RC1 Other informationNo response
|
#90436 might fix this. |
I'm having this issue in production .NET8, AOT WASM. Happens regardless whether MONO interpreter: NIY encountered in method .ctor dotnet.runtime.8.0.0.14kkjimq5k.js:3 Error: [MONO] * Assertion: should not be reached at /__w/1/s/src/mono/mono/mini/interp/interp.c:3863
Which repeats 4 times with other stack traces, and then ultimately: ExitStatus {name: 'ExitStatus', message: 'Program terminated with exit(1)', status: 1} Interpreted works fine. AOT also worked fine in .NET6. |
Can confirm the same issue is still reproducing in final .NET 8.0. Was the mentioned PR merged to 8.0 or it's postponed to 9.0? (the PR is missing milestone) |
The fix was merged recently. Unfortunately, it didn't make it to the .NET8 GA. It will for sure be in .NET9. It might be able to be released as part of .NET8 service1. But I can't guarantee that right now. |
Could you try to build your app after deleting all the build artifacts of your app and turning off |
@fanyang-mono apologies, I stand corrected. It DOES work properly when Do we know the qualitative cause and is it something we can try to avoid until the fix makes it into production? Or is |
@fanyang-mono gotcha thank you. Stripping IL isn't critical now that I can get AOT working without it. |
@fanyang-mono I am hitting this error without stripping on a clean debug build. I have cleared out the
My build options are
Please let me know if there is other information that you need to investigate this (or if I should move this to a separate issue entirely). Thank you! |
@sschoener Thanks for reporting this issue. This should not happen to a fresh build with |
Please find the project here: BlazorLineFilter.zip It is a tiny project created from the Blazor WebAssembly template. It consists of a single page with some JavaScript-interop to open/close files on the users file system. To reproduce, open the solution, build for Let me know if I can be of further assitance. |
> dotnet --info
.NET SDK:
Version: 8.0.101
Commit: 6eceda187b
Workload version: 8.0.100-manifests.1c08acc9 My <PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<InvariantGlobalization>true</InvariantGlobalization>
<BlazorEnableTimeZoneSupport>false</BlazorEnableTimeZoneSupport>
<BlazorWebAssemblyPreserveCollationData>false</BlazorWebAssemblyPreserveCollationData>
<WasmExceptionHandling>true</WasmExceptionHandling>
<WasmSIMD>false</WasmSIMD>
</PropertyGroup> Publishing with dotnet publish UI.csproj -c Release -p:RunAOTCompilation=true -p:WasmStripILAfterAOT=false But this crashes with dotnet publish UI.csproj -c Release -p:RunAOTCompilation=true -p:WasmStripILAfterAOT=true The latter does produce noticeably smaller files, which is nice, e.g. @fanyang-mono you mentioned that it should be fixed in #90436. I see that PR is merged now. When is it going to be release? That size improvement would be great to have. |
Just encountered this myself too. exactly the same issue as @iSeiryu describes above. Looks like we have to wait for .NET 9 for the fix? No chance of getting it in a .NET 8 update?? UPDATE: Running AOT + WasmStripILAfterAOT publish of our Blazor WASM Standalone app AS ADMINISTRATOR seemingly broke my .NET install altogether... I cannot even start our ASP.NET app anymore (separate from WASM app) in debug mode. I My Windows is completely messed up from this... I cannot get it fixed. Created issue #98041 |
Sorry about the delay. The fix has been shipped as part of .NET9 Preview1. Please download the latest .NET from https://dotnet.microsoft.com/en-us/download/dotnet/9.0 to see if you issue has been resolved. |
Closing this now, as all the issues related to WasmStripILAfterAOT should have been fixed. |
Description
I've tried enabling recently added
<WasmStripILAfterAOT>
(dotnet/core#8439 (comment)), but it breaks the application and results in slightly larger build size (5.05MB vs 5.06MB).Reproduction Steps
App
directory runnpm install
dotnet publish backend
npm run dev
App/public/bin
(5.05MB on my end)<WasmStripILAfterAOT>true</WasmStripILAfterAOT>
toApp/backend/Backend.WASM/Backend.WASM.csproj
propertiesdotnet publish backend
to re-build the solutionExpected behavior
App works as before and binaries size is at least not larger than before.
Actual behavior
Binaries size is slightly larger (5.06MB on my end) and app crashes with the following log:
Browser console log
Regression?
No.
Known Workarounds
None.
Configuration
.NET 8 RC1
Windows 10 x64
Other information
No response
The text was updated successfully, but these errors were encountered: