-
Notifications
You must be signed in to change notification settings - Fork 528
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
DSO handling for like-named libraries is broken #9081
Comments
So, I've been pondering how to fix this issue on our end and I don't see a way to get rid of the ambiguity involved here. Here's what's going on: We have two input items:
At build time, the AOT compiler adds a third item, the AOT image generated from %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 Input names of Putting aside the fact that the lookup table should not have any entries with the same hashes, we have a decision to make when MonoVM asks us to dlopen a library named
The immediate solution, and one which I'm going to implement now, is to completely ignore The better solution is to avoid the ambiguity. In order to do that, I think the best way would be if Mono JIT asked to load /cc @lambdageek |
I'm not sure this is true. Unless I'm completely misreading the code, the name we ask for is That is the first thing we try to find is
I think if we were to implement this, I would suggest something like (This code path would be primarily android only - ios and wasm use static linking for AOT images so they never do the dlopen call at all)
I think we can probably add a new flag to I'll add a comment to dotnet/runtime#104397 |
@lambdageek I'll get to working on this this week, will log everything relevant and we'll see what's what. But I think the runtime requests |
With regards to |
Any status update on this? |
As dotnet/runtime#104397 is still open, I can't implement the original plan as described above but I'll see if I can come up with a temporary workaround until the runtime issues are fixed. |
PR #9117 implements a new approach to fixing/working around this issue (the runtime changes @lambdageek is working on are still needed and useful) - it splits the "regular" DSO cache and AOT DSO cache into separate sets. This way we avoid ambiguities like the one in this issue. The PR knows when it is being asked to find a shared library for a p/invoke (this is done via the p/invoke override MonoVM hook, so Mono itself doesn't load the DSO in question) and when Mono might be asking to load the AOT DSO. In the latter case, the PR first checks the AOT DSO cache for a match and then the "regular" cache, as we know p/invoke calls won't be going along this code path. Attached are binaries from the PR build which contain the changes. @daltzctr to test them, you'll need to find location of the .NET for Android SDK on your disk and replace The test app doesn't crash for me with those changes, it however crashes with something else:
This is a very weird exception, which might have to do with marshal methods support in our runtime. If you hit the same issue, disable marshal methods by setting the |
Android framework version
net9.0-android
Affected platform version
.NET 9 Preview 5
Description
It crashes
Steps to Reproduce
Run the following project in release mode with .NET 9 Preview 5 workloads.
Repro: https://github.com/daltzctr/maui-dotnet9-crash
Did you find any workaround?
Disable AOT
Relevant log output
No response
The text was updated successfully, but these errors were encountered: