Repository navigation
[mono] MAUI release mode crash Assertion at /__w/1/s/src/mono/mono/mini/aot-runtime.c:5220, condition `plt_entry' not met #95406
Description
Activity
hi @jeffgoku thanks for the bug report. Do you have a sample app that demonstrates the issue that you could share with us?
This is probably some profiled AOT issue. I think MAUI ships an AOT profile for android that is used by default on Android
/cc @jonathanpeppers
@jeffgoku If you want to try, you can "AOT everything" by setting
AndroidEnableProfiledAot=falsein your.csproj.It's worth checking if that fixes it.
8 remaining items
Enabling trimming for debug didn't change much for me,
Debugwas running fine.At the same time, I can confirm that the combination of
<AndroidEnableProfiledAot>False</AndroidEnableProfiledAot> <EnableLLVM>True</EnableLLVM>runs okay on
Release, while<EnableLLVM>True</EnableLLVM>randomly crashes with
condition 'plt_entry' not metmessage.Reacted by Timur-FilatovCan confirm setting AndroidEnableProfiledAot=false stops crashing of my release app caused by "aot-runtime.c:5220, condition `plt_entry' not met", but the APK is now 63mb, twice the size when I don't have that value set to false (and 3x the size of the Xamarin forms APK version the project was migrated from), the compile time on a core i9 is through the roof.
@jonathanpeppers Is the default MAUI-shipped Android AOT profile at cause here? I don't mind the extra AOT time and space requirements but I am simply curious. Also I vaguely remember that creating your own AOT profile in .NET Android was not possible, yet?
There are some known issues mixing:
<AndroidEnableProfiledAot>True</AndroidEnableProfiledAot> <EnableLLVM>True</EnableLLVM>
The reason being when we record an AOT profile (recorded under JIT), some of the wrong code paths are taken for checks like
RuntimeFeature.IsSomeHardwareInstrinsticSupported. I don't think we have a solution for that.But this combination should work:
<AndroidEnableProfiledAot>False</AndroidEnableProfiledAot> <EnableLLVM>True</EnableLLVM>
Or this one:
<!-- Note this is the default if you left these blank --> <AndroidEnableProfiledAot>True</AndroidEnableProfiledAot> <EnableLLVM>False</EnableLLVM>
You can record your own profile with this NuGet package, but it wouldn't solve this issue:
Reacted by Mathias Jørgensen, indieshack, Nick Kovalsky, veringm, Poko and AndreasThanks - rebuilt with the last setting you mention setting and the APK is back to the regular maui APK size and doesn't crash.
I too experience this issue. If one was to choose between
<AndroidEnableProfiledAot>False</AndroidEnableProfiledAot> <EnableLLVM>True</EnableLLVM>and
<AndroidEnableProfiledAot>True</AndroidEnableProfiledAot> <EnableLLVM>False</EnableLLVM>I believe AndroidEnableProfiledAot=True is important if app-size is an issue, but the best performance on runtime will be with AndroidEnableProfiledAot=False and EnableLLVM=True. Is that generally correct?
If anyone is still looking for a repro of this issue then my ImageSharpMAUITest (as of commit
ecdf0d92a7195d8f0e9fb74c64cdca4e53db029b) will reproduce it.In the csproj I have
<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android' AND '$(Configuration)' == 'Release'"> <EnableLLVM>true</EnableLLVM> <RunAOTCompilation>true</RunAOTCompilation> <AndroidEnableProfiledAot>false</AndroidEnableProfiledAot> </PropertyGroup>
which runs fine. Removing
AndroidEnableProfiledAotand hitting theRun all testsin the application itself will result in a crash.07-27 14:06:30.804 7895 7961 E gesharpmauitest: * Assertion at /__w/1/s/src/mono/mono/mini/aot-runtime.c:5220, condition `plt_entry' not met
07-27 14:06:30.806 7895 7961 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 7961 (.NET TP Worker), pid 7895 (gesharpmauitest)I did some different things of using different combinations of
EnableLLVM,RunAOTCompilation, andAndroidEnableProfiledAotdetermining performance and filezie. It is written up in this comment.The TLDR is,
<EnableLLVM>false</EnableLLVM> <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
Having this setup appears to be the same of just deleting the 2 lines.
<EnableLLVM>true</EnableLLVM> <AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
Will give more performance, but at a larger filesize.
<RunAOTCompilation>true</RunAOTCompilation>
May be implied by
EnableLLVM. Googling "RunAOTCompilation docs" did not lead to any docs on the first page of results, I don't care enough to try hunt ths down on a Saturday to see if that is true or not 😅The problem still exists. When
<EnableLLVM>true</EnableLLVM> <RunAOTCompilation>true</RunAOTCompilation>GoToAsync() is likely to cause a crash.
I tested different combinations of the two optimizations, but strangely, at least in my project, the size of the app with LLVM enabled alone (21.3MB) is significantly smaller than the app with AOT enabled alone (31.3MB), while the size of the app with both LLVM and AOT enabled is 30.3MB, so I finally chose to enable LLVM and disable AOT.
Make sure you call this one on UI thread. The faster the app works (aot) the more likely your threads execution flow will be differentl from what you had on Debug.
I also have a repro running into this. https://github.com/ThreeSevenths/MauiSqliteIssue
The workaround posted by @beeradmoore on 2024-07-27 does work for my test app. Although I lost about 5% perf with this combination.
I think there's an issue with visibility here.
<AndroidEnableProfiledAot>is enabled by default, and<EnableLLVM>is not. If a dev adds<EnableLLVM>they could experience this if they like me, naively are working on performance in their apps. No warnings are triggered, and one must identify the correct log entry for the failed assertion to arrive at this GH issue and find a workaround for the problem they are facing. This is time consuming and has many cliffs to fall off and not arrive at this GH issue. The fact that it's been open for more than 18 months does not help. I see this and other issues like it as endemic to the Maui project, and am concerned about the long term viability of any apps developed with it. I hope the team understands that these pitfalls might only affect a small percentage of users from telemetry, but they should still be addressed.Reacted by Timur-FilatovHi @jonathanpeppers
Your contribution to MAUI optimization is difficult to overestimate.Regarding the current issue, we suggest all MAUI users either to make an app work ~2 times slower with LLVM disabled, but it will start 2 times faster with AOT enabled, or to start 2 times slower, but work ~2 times faster.
Is this the best we can offer (with the love)?I've converted one of the apps to React Native, it starts 0.5 sec compared to 6 sec for MAUI. Also same lists scrolling without any lags and navigation is 2-3 times faster compared to MAUI CollectionView.
It's not good to ignore this bug in this conditions, even if sometimes MAUI is faster in runtime/logic/bindings.
Thought shadows & swipe view can also be faster on MAUI, but shadows are not working for part of devices due to Android bug (was working in .net8), and some devices will stay without shadows forever.My clients complain about low performance of scrolling and navigation on middle Android devices that were bought 1-2 years ago, that it is impossible to work on them because of the lags, I can't offer them to replace the entire fleet of corporate devices with top ones, or to rewrite entire app to RN or anything else.
Currently when using AOT + LLVM without ProfiledAot, apk is 74 MB (AndroidStripILAfterAOT can shrink to 69 MB), there app starts 4 sec, but Azure Blobs not downloading,
If enabling ProfiledAot, Azure Blobs starts to download, but got this "plt_entry not met" crash every 1 minute in random places, the apk is 49 MB, starts 4 sec.Now disabled AOT at all, app starts 8 sec, but enabled LLVM, so it works faster and apk is 43 MB
(set single arm64 abi per build, because in .net9 there is another bug, if building 2 abis, each apk is 1.5 times larger: 65 MB).@Timur-Filatov if there is a specific thing you'd like us to focus on, can you file an issue here?
The conversation here is more about mixing Profiled AOT and LLVM, which doesn't work today.
Are the numbers from app sizes above from Google Play? As you're likely seeing the size of all architectures, densities, languages combined. Google Play knows how to split up app bundles. To get an estimate you could build a single architecture to measure app size, like
-r android-arm64.In iOS, we've option to AOT compile everything, while it fallbacks to Interpreter automatically using the following configuration:
<MtouchInterpreter>-all</MtouchInterpreter>when the currently running code block is not compatible with AOT.
More info at https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter
Note that this option is not the same as<UseInterpreter>true</UseInterpreter>In Android, we can AOT compile everything by setting
<RunAOTCompilation>true</RunAOTCompilation>and<AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>and I think it automatically fallbacks to JIT when the running code is not compatible.What's wrong with
<EnableLLVM>true</EnableLLVM>? Why it can't fallback to JIT in case the running code is not compatible with it?Do we expect things to change regarding to the new Native AOT?
NativeAOT doesn't have an interpreter, and you get build warnings for APIs that require it. APIs that require an interpreter won't work at all on NativeAOT.
Description
Random crash at the assertion in release mode, no problem for debug mode
Reproduction Steps
No repro, only happened in release mode
Expected behavior
should not crash
Actual behavior
crash
Regression?
works in dotnet 7
Known Workarounds
No response
Configuration
Other information
No response