Repository navigation
Release crash on unmanagedcallersonly framework code #7876
Description
Activity
- addedArea: App RuntimeIssues in `libmonodroid.so`.Issues in `libmonodroid.so`.needs-triageIssues that need to be assigned.Issues that need to be assigned.
on Mar 11, 2023 /cc @MichalPetryka
/cc @MichalPetryka
The backtrace seems to suggest that either of:
https://github.com/xamarin/xamarin-android/blob/928e7b97f81b3fcaa4655dbc4b8a2f5667e5d38b/src/Mono.Android/Android.Runtime/JNIEnvInit.cs#L54-L57
https://github.com/xamarin/xamarin-android/blob/928e7b97f81b3fcaa4655dbc4b8a2f5667e5d38b/src/Mono.Android/Android.Runtime/JNIEnvInit.cs#L78-L81is missing
UnmanagedCallersOnlyin runtime here:
https://github.com/xamarin/xamarin-android/blob/928e7b97f81b3fcaa4655dbc4b8a2f5667e5d38b/src/monodroid/jni/monodroid-glue.cc#L1100
or here:
https://github.com/xamarin/xamarin-android/blob/928e7b97f81b3fcaa4655dbc4b8a2f5667e5d38b/src/monodroid/jni/monodroid-glue.cc#L1123which hints that something causes C# DLLs built for .Net Framework to be used with .Net
8p1 runtime.@333fred @MichalPetryka my first suspicion is, indeed, that there's a mix-up in the packaged assemblies. It is usually caused by something in the
obj/folder getting messed up. Unfortunately, it's impossible to say what's the problem from a runtime crash. We will need a binlog of a build that crashes - please start building with-blpassed todotnet build(or its equivalent setting in the IDE) and attach the problematic build's one here, once the crash happens. Another thought I had about it is whether your project uses any Android libraries that target classic XA? They don't need to be part of the actual application, just part of the solution. It could potentially cause this kind of problem.If it is indeed a
bin/objissue, then you'll be able to get to the good state by removingbinandobj, which is a pain, but will get you going until we can pin-point the issue.- addedneed-infoIssues that need more information from the author.Issues that need more information from the author.and removedneeds-triageIssues that need to be assigned.Issues that need to be assigned.
on Mar 13, 2023 If it is indeed a bin/obj issue, then you'll be able to get to the good state by removing bin and obj, which is a pain, but will get you going until we can pin-point the issue.
I suspect this is correct, as I've noticed that doing complete rebuild seems to fix it. I'll grab the binlog from VS tonight.
- ghost removedneed-infoIssues that need more information from the author.Issues that need more information from the author.
on Mar 13, 2023 - ghost addedneed-attentionA xamarin-android contributor needs to reviewA xamarin-android contributor needs to review
on Mar 13, 2023 Of course when I go to collect logs tonight what was crashing for me nearly every second build last night is doing nothing at all tonight... I'll keep trying to get a log.
Managed to get the logs from a build. It happened after a
CTRL+F5with minor changes (moved a comment around, essentially). As this is not an open source app I'm not going to attach the binlogs here, but will put them on a network share tomorrow for @jonathanpeppers and @dellis1972 to take a look at.https://microsoft-my.sharepoint.com/:f:/p/frsilb/EuN4UGo4MLBGppt8K1Dn1HYB78DK7cSRA9OdtXMP9wS02A?e=R7d5TP should be accessible to MSFT folks. It has the binlogs from both build and deploy actions in VS, as well as the logcat output from
adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all, the built apk, and the zippedbindirectory from when it occured.I got this on .NET MAUI 7 when running release any suggestion ?
@Strypper in talking with @jonathanpeppers, a workaround should be putting
<AndroidEnableMarshalMethods>false</AndroidEnableMarshalMethods>in your project file. However, if you're seeing this on .NET 7 and not 8, I suspect it may be something different, and the MAUI team might want to take a look at your logs 🙂.If it is indeed a bin/obj issue, then you'll be able to get to the good state by removing bin and obj, which is a pain, but will get you going until we can pin-point the issue.
I suspect this is correct, as I've noticed that doing complete rebuild seems to fix it. I'll grab the binlog from VS tonight.
Just happened on Release for me, deleted bin/obj folders for a complete rebuild and the problem was gone. .Net 7.
- added a commit that references this issue
on Oct 16, 2023 cleaning does not fix it, as it will reappear sometimes when making seemingly valid changes
Tracking this via #8253.
- locked and limited conversation to collaborators
on Jun 17, 2024
Android application type
Android for .NET (net6.0-android, etc.)
Affected platform version
VS 17.6p1/.NET 8p1
Description
I have a maui app (closed source, unfortunately, but my alias is frsilb if the logs I've attached aren't enough and we need to do more debugging) that uses both EF Core and SignalR. I'm getting a crash in release mode:
The crash doesn't happen on every build of the app, but when it does happen, it happens on every launch of that build, and it seems to happen more often than not. I've been unable to minimize it to a single cause yet. No crash occurs when running in debug mode.
Steps to Reproduce
I've attached the logs, let me know if they're not enough to figure it out and we can debug my app. I haven't been able to minimize the crash.
Did you find any workaround?
None.
Relevant log output
Here's the logs with the backtrace.