-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
.NET 9: Android application crashes in release mode with Skiasharp #104397
Comments
Discussed with @grendello and tehre's actually two problems here:
runtime/src/mono/mono/mini/aot-runtime.c Lines 2100 to 2114 in 4f96b8f
if we found |
A more robust solution here is to make the runtime native library loader do exactly what the Android SDK is attempting to hack in using the existing native library fallback hooks. From dotnet/android#9081 (comment):
I think we can do this pretty surgically by adding a new mono cmake flag runtime/src/mono/mono/mini/aot-runtime.c Line 2049 in e336326
#ifndef MONO_AOT_EXACT_SCHEME
aot_name = g_strdup_printf ("%s%s", assembly->image->name, MONO_SOLIB_EXT);
#else
#define MONO_AOT_SCHEME_PREFIX "mono-aot://"
aot_name = g_strdup_printf ("%s%s", MONO_AOT_SCHEME_PREFIX, assembly->image->name);
#endif
Then at runtime/src/mono/mono/mini/aot-runtime.c Line 2053 in e336326
#ifndef MONO_AOT_EXACT_SCHEME
sofile = mono_dl_open (aot_name, MONO_DL_LAZY, load_error);
#else
sofile = mono_dl_open (aot_name, MONO_DL_LAZY | MONO_DL_FALLBACK_ONLY, load_error);
#endif and also runtime/src/mono/mono/mini/aot-runtime.c Lines 2062 to 2084 in e336326
And finally implement the new runtime/src/mono/mono/utils/mono-dl.c Lines 249 to 279 in e336326
don't call runtime/src/mono/mono/utils/mono-dl.c Lines 280 to 336 in e336326
|
Any update on this? |
#104397 (comment) has been address in #106026 and is going to be part of .NET 9. The remaining work #104397 (comment) is moved to .NET 10. |
Fixes: #9081 Context: dotnet/runtime#104397 Context: dotnet/runtime#106026 Context: #9081 (comment) Context: c227042 ("Compatibility is fun") Consider a P/Invoke method declaration: [DllImport("libSkiaSharp")] static extern void gr_backendrendertarget_delete(IntPtr rendertarget); Historically, when attempting to resolve this method, Mono would try loading the following native libraries: * `libSkiaSharp` (original name) * `libSkiaSharp.so` (add `.so` suffix) * `liblibSkiaSharp` (add `lib` prefix) * `liblibSkiaSharp.so` (`lib` prefix + `.so` suffix) .NET for Android would further permute these names, *removing* the `lib` prefix, for attempted compatibility in case there is a P/Invoke into `"SkiaSharp"`. The unfortunate occasional result would be an *ambiguity*: when told to resolve "SkiaSharp", what should we return? The information for `libSkiaSharp.so`, or for the *AOT'd image* of the assembly `SkiaSharp.dll`, by way of `libaot-SkiaSharp.dll.so`? %struct.DSOCacheEntry { i64 u0x12e73d483788709d, ; from name: SkiaSharp.so i64 u0x3cb282562b838c95, ; uint64_t real_name_hash i1 false, ; bool ignore ptr @.DSOCacheEntry.23_name, ; name: libaot-SkiaSharp.dll.so ptr null; void* handle }, ; 71 %struct.DSOCacheEntry { i64 u0x12e73d483788709d, ; from name: SkiaSharp.so i64 u0x43db119dcc3147fa, ; uint64_t real_name_hash i1 false, ; bool ignore ptr @.DSOCacheEntry.7_name, ; name: libSkiaSharp.so ptr null; void* handle }, ; 72 If we return the wrong thing, then the app may crash or otherwise behave incorrectly. Fix this by: * Splitting up the DSO cache into AOT-related `.so` files and everything else. * Updating `PinvokeOverride::load_library_symbol()` so that the AOT files are *not* consulted when resolving P/Invoke libraries. * Updating `MonodroidDl::monodroid_dlopen()` -- which is called by MonoVM via `mono_dl_fallback_register()` -- so that the AOT files *are* consulted *first* when resolving AOT images. When dotnet/runtime#104397 is fixed, it will make the AOT side of the split more efficient as we won't have to permute the shared library name as many times as now.
Description
I was directed to submit an issue here by the dotnet android development team. I upgraded my MAUI application to .NET 9 Preview 5 and have occurred release mode crashes whenever initializing a view that contains Skiasharp.
Reproduction Steps
Expected behavior
It does not crash
Actual behavior
It crashes
Regression?
Yes. This worked in .NET 8
Known Workarounds
<RunAOTCompilation>False</RunAOTCompilation>
Configuration
Other information
This is not specific to any MAUI version and only occurs if skiasharp has to be loaded. I have attached some logs that may be useful below. A managed stack trace is not available and I have no other logs besides ones directly shared with Microsoft Staff. Contact @grendello for the detailed log.
The text was updated successfully, but these errors were encountered: