Debug feature broken on Android 9 with VS2019 & VS2022 #7658
Comments
jiro-san
added
Area: App Runtime
grendello
added
Area: Debugger
|
I suspect your issue might be that the can you try adding the following to your This will ensure that the x84 (or x86_64) native libraries are included in the applicastion package. As for the Filter Exceptions you will need to report tht issue via the Visual Studio 'Report an issue' menu item since it is a different team which deals with that. |
|
Our app is using .so files compiled for armeabi-v7a, and we don't have the version for arm64-v8a yet. If we enable arm64-v8a we get "[mono-rt] [ERROR] FATAL UNHANDLED EXCEPTION: System.NotSupportedException" when trying to initialize our so file. We will try getting support for x64-v8a too, but since x64-v8a ARM CPUs are also compatible with armeabi-v7a libraries (I didn't have time yet to look for the official information from ARM but it works when we try our app, without debugging), I did not expect this issue. So we will try to add x64-v8a support, but if you can please comment if you see it as a bug or as an expected behavior. |
|
So we are going to need some diagnsotic build logs since I am unable to repo the VMWare issue with the Android x86 Image you linked to. So from a developer command prompt can you run the following command on your project after deleting the bin & obj directories. Do this against your Android 9 device , not the VMWare image. This will produce a msbuild.binlog file which you can zip up and sent do us. next from an Android Command Prompt (There should be a menu item in VS) run Then run the app on the device. Once the app crashes presss Ctrl-C to exit |
|
Hi @jiro-san. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
|
Hello, oh ok sorry i was not clear, you can reproduce the same issue with an app that uses x86 libraries (.so files) running on the VM i provided (the VM runs with x86_64 architecture, so what we said about armeabi-v7a and arm64-v8a also applies here). |
ghost
added
need-attention
|
So I re testing again with the following settings on the x86_64 VMWare Image This is with an vamilla Xamarin.Anroid app. This worked fine for me. The zip only contained the arm v7 and x86 runtimes for Xamarin.Android, and the app worked as expected. So it looks like I'm going to need those logs and the logcat output. |
dellis1972
added
need-info
|
Hi @jiro-san. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
|
Hello again. Can you try it please? It uses a native library libMatrix.so that does simple matrix multiplication. You can see the configuration in the .csproj:
Attached files: |
ghost
added
need-attention
|
I wanted to give you an update. I managed to repo the issue with your sample, thank you. The core of the problem is this For some reason we cannot load mscorlib.dll which is packaged. This is confusing because the app loads find when we don't attach the debugger. I will need to discuss this issue with my team to see if we can figure out what is going on. |
|
Any progress? |
|
@grendello when you get a moment can you take a look at this issue. Its very odd. |
|
@dellis1972 The error message's "Internal error" part is the error string we get from Mono, so I suppose the best course of action is to enable more logging from the Mono side. @jiro-san can you run your app after issuing the following commands from the command line: > adb shell setprop debug.mono.log default,assembly,mono_log_level=debug,mono_log_mask=all
> adb logcat -G 16M
> adb logcat -c
rem Start your application here and wait for it to crash
> adb logcat -d > log.txtAnd then attach |
|
@grendello Ok I will take those logs, but please note that the issue is reproducible in a "neutral" environment with the sample app I provided to dellis1972 and the OS image of Android 9.0 I provided in the first post. |
|
@grendello |
I appreciate that, thank you, however I don't work on Windows and I don't have VS readily available for testing. Thus the fastest course of action was to ask you for the logs, thank you for providing them. Would you be able to do another test? I wonder if the app can be debugged if these steps are followed:
|
|
I've managed to reproduce the issue locally, and the problem appears to be this error: Note the path from the build bot ( @lambdageek any idea who would be able to look into it on Mono side? |
|
The issue is that The fix is that the underlying The This affects mono/mono I will open the various PRs |
Emebedders that call `mono_assembly_load_from_full` may observe a
non-NULL return value and an uninitialized MonoImageOpenStatus, which
may lead to incorrect diagnostics in code like:
```
MonoImageOpenStatus status;
MonoAssembly *assembly = mono_assembly_load_from_full (image, name,
status, refonly);
if (!assembly || status != MONO_IMAGE_OK) {
fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status));
abort();
}
```
Which will print `Failure due to: Internal error`
Addresses dotnet/android#7658
Emebedders that call `mono_assembly_load_from_full` may observe a
non-NULL return value and an uninitialized MonoImageOpenStatus, which
may lead to incorrect diagnostics in code like:
```
MonoImageOpenStatus status;
MonoAssembly *assembly = mono_assembly_load_from_full (image, name,
status, refonly);
if (!assembly || status != MONO_IMAGE_OK) {
fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status));
abort();
}
```
Which will print `Failure due to: Internal error`
Addresses dotnet/android#7658
Manual backport of dotnet/runtime#80949 to mono/mono Emebedders that call `mono_assembly_load_from_full` may observe a non-NULL return value and an uninitialized MonoImageOpenStatus, which may lead to incorrect diagnostics in code like: ``` MonoImageOpenStatus status; MonoAssembly *assembly = mono_assembly_load_from_full (image, name, status, refonly); if (!assembly || status != MONO_IMAGE_OK) { fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status)); abort(); } ``` Which will print `Failure due to: Internal error` Addresses dotnet/android#7658
Manual backport of dotnet/runtime#80949 to mono/mono Emebedders that call `mono_assembly_load_from_full` may observe a non-NULL return value and an uninitialized MonoImageOpenStatus, which may lead to incorrect diagnostics in code like: ``` MonoImageOpenStatus status; MonoAssembly *assembly = mono_assembly_load_from_full (image, name, status, refonly); if (!assembly || status != MONO_IMAGE_OK) { fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status)); abort(); } ``` Which will print `Failure due to: Internal error` Addresses dotnet/android#7658
lambdageek
added
Area: Mono Runtime
Emebedders that call `mono_assembly_load_from_full` may observe a
non-NULL return value and an uninitialized MonoImageOpenStatus, which
may lead to incorrect diagnostics in code like:
```
MonoImageOpenStatus status;
MonoAssembly *assembly = mono_assembly_load_from_full (image, name,
status, refonly);
if (!assembly || status != MONO_IMAGE_OK) {
fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status));
abort();
}
```
Which will print `Failure due to: Internal error`
Addresses dotnet/android#7658
Emebedders that call `mono_assembly_load_from_full` may observe a
non-NULL return value and an uninitialized MonoImageOpenStatus, which
may lead to incorrect diagnostics in code like:
```
MonoImageOpenStatus status;
MonoAssembly *assembly = mono_assembly_load_from_full (image, name,
status, refonly);
if (!assembly || status != MONO_IMAGE_OK) {
fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status));
abort();
}
```
Which will print `Failure due to: Internal error`
Addresses dotnet/android#7658
* [mono][loader] Set status on success Manual backport of dotnet/runtime#80949 to mono/mono Emebedders that call `mono_assembly_load_from_full` may observe a non-NULL return value and an uninitialized MonoImageOpenStatus, which may lead to incorrect diagnostics in code like: ``` MonoImageOpenStatus status; MonoAssembly *assembly = mono_assembly_load_from_full (image, name, status, refonly); if (!assembly || status != MONO_IMAGE_OK) { fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status)); abort(); } ``` Which will print `Failure due to: Internal error` Addresses dotnet/android#7658 * [loader] Make mono_image_laod_time_date_stamp a no-op on Android Avoid an mmap that will fail since Android uses a custom loader and the assemblies aren't on disk
Emebedders that call `mono_assembly_load_from_full` may observe a
non-NULL return value and an uninitialized MonoImageOpenStatus, which
may lead to incorrect diagnostics in code like:
```
MonoImageOpenStatus status;
MonoAssembly *assembly = mono_assembly_load_from_full (image, name,
status, refonly);
if (!assembly || status != MONO_IMAGE_OK) {
fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status));
abort();
}
```
Which will print `Failure due to: Internal error`
Addresses dotnet/android#7658
Co-authored-by: Aleksey Kliger <alklig@microsoft.com>
|
I am experiencing the same issue (though running on a custom android device running Android 7.1.1). Any idea when the proposed fix will be released in an update to Mono.Android? |
|
Can we close it? The issue has been fixed and backported. |
Fixes: dotnet#7658 Changes: mono/mono@6dd9def...73df89a * mono/mono@73df89a73d2: Fix xar url again * mono/mono@36fd1837d0d: Switch back to original xar version * mono/mono@5bbc709e5dc: Fix xar download url * mono/mono@3cb47d8b4dc: [mono] Use `unsigned char` when computing UTF8 string hashes (mono/mono#21633) * mono/mono@a102a350e53: [2020-02] [mono][loader] Set status on success; avoid mmap on Android (mono/mono#21610) * mono/mono@74f85c2ac33: Fix url to gtksharp msi * mono/mono@2f7d584ad2b: Fix build on macOS 13 / Xcode 14 (mono/mono#21597) * mono/mono@03b09960787: Disable a failing test
|
I can't believe I forgot about this! #8054 @teo-tsirpanis: .NET 7 has had the fix backported. Classic Xamarin.Android has not (oops), and #8054 does so. |
|
@jonpryor Do we have any idea when this will be released? It's killing me not being able to debug my app... |
Fixes: #7658 Changes: mono/mono@6dd9def...73df89a * mono/mono@73df89a73d2: Fix xar url again * mono/mono@36fd1837d0d: Switch back to original xar version * mono/mono@5bbc709e5dc: Fix xar download url * mono/mono@3cb47d8b4dc: [mono] Use `unsigned char` when computing UTF8 string hashes (mono/mono#21633) * mono/mono@a102a350e53: [2020-02] [mono][loader] Set status on success; avoid mmap on Android (mono/mono#21610) * mono/mono@74f85c2ac33: Fix url to gtksharp msi * mono/mono@2f7d584ad2b: Fix build on macOS 13 / Xcode 14 (mono/mono#21597) * mono/mono@03b09960787: Disable a failing test
Same |
* [mono][loader] Set status on success Manual backport of dotnet/runtime#80949 to mono/mono Emebedders that call `mono_assembly_load_from_full` may observe a non-NULL return value and an uninitialized MonoImageOpenStatus, which may lead to incorrect diagnostics in code like: ``` MonoImageOpenStatus status; MonoAssembly *assembly = mono_assembly_load_from_full (image, name, status, refonly); if (!assembly || status != MONO_IMAGE_OK) { fprintf(stderr, "Failure due to: %s\n", mono_image_strerror (status)); abort(); } ``` Which will print `Failure due to: Internal error` Addresses dotnet/android#7658 * [loader] Make mono_image_laod_time_date_stamp a no-op on Android Avoid an mmap that will fail since Android uses a custom loader and the assemblies aren't on disk
|
This seems to be fixed in .NET 8+. |
Android application type
Classic Xamarin.Android (MonoAndroid12.0, etc.)
Affected platform version
VS2022 17.4.3 / VS2019 16.9.3
Description
There are big stability issues when debugging a Xamarin.Android app with VS2022 or VS2019.
We are using Android x86 (Android version 9 - Pie) to debug our app in a VMware virtual machine because the app needs to be deployed on an embedded system that uses Android Pie.
Also we have the same issues with real android 9 device based on ARM processor so it is not linked to x86, I talk about it here because it is a good neutral environment to reproduce the issue.
We tried running with different development environment, in VS2019 and VS2022, and here are the issues we faced:
With VS2022
When Fast Deployment is unchecked in our app we get the following log in debug output:
With VS2019
Those issues with VS2019 & 2022 are hindering a lot our debugging efficiency, since the issues with VS2022 made us prefer VS2019, but often we crash just trying to get information about a variable.
Is there any way to work around these issues, or to solve them? The best would be that all works fine in VS2022 so we could forget about VS2019 all together.
Below are the version information:
VS2022
VS2019
Steps to Reproduce
With VS2022:
(vmware image can be downloaded from here: https://www.osboxes.org/android-x86/#android-x86-9-0-r2-vmware)
Result:
Note: when launching the app there is a warning about exception filters:
This debug engine does not support exception conditions. The condition(s) will be ignored.
With VS2019:
(vmware image can be downloaded from here: https://www.osboxes.org/android-x86/#android-x86-9-0-r2-vmware)
Result:
When performing normal debug operations like stopping on a breakpoint for some time or checking local variables or list contents the debugger crashes (resulting in application crash or freeze).
Did you find any workaround?
No response
Relevant log output
No response
The text was updated successfully, but these errors were encountered: