Custom Profile with Startup Tracing fails deployment on Visual Studio for Mac

[MathieuJack]

This issue is a continuation of #4566

Steps to Reproduce

Could not isolate the problem in a small application. Problem occurs unfortunlatly only with my (big)project.

1. In VS for Mac, I open my solution, I select release mode, enable startup tracing, check that my custom.aprof is attached to the project.
2. Hit "Start debugging"

Expected Behavior

My app is deployed on my device.

Actual Behavior

My app is not deployed on my device.
VS shows an error.

Version Information

=== Visual Studio Community 2019 for Mac ===

Version 8.5.4 (build 12)
Installation UUID: 1d2919a4-549f-4c46-811b-dbc22b18911a
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac 6.14.1.39 (d16-5 / 30e8706b4)

Package version: 608000123

=== Mono Framework MDK ===

Runtime:
Mono 6.8.0.123 (2019-10/1d0d939dc30) (64-bit)
Package version: 608000123

=== Roslyn (Language Service) ===

3.5.0-beta4-20125-04+1baa0b3063238ed752ad1f0368b1df6b6901373e

=== NuGet ===

Version: 5.4.0.6315

=== .NET Core SDK ===

SDK: /usr/local/share/dotnet/sdk/3.1.200/Sdks
SDK Versions:
3.1.200
3.1.102
3.1.101
3.0.101
3.0.100
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.8.0/lib/mono/msbuild/Current/bin/Sdks

=== .NET Core Runtime ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
3.1.2
3.1.1
3.0.1
3.0.0
2.1.17
2.1.16
2.1.15
2.1.14
2.1.13

=== Xamarin.Profiler ===

Version: 1.6.12.29
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Updater ===

Version: 11

=== Apple Developer Tools ===

Xcode 11.4.1 (16137)
Build 11E503a

=== Xamarin.Mac ===

Version: 6.16.0.13 (Visual Studio Community)
Hash: b75deaf82
Branch: d16-5-xcode11.4
Build date: 2020-04-01 21:33:18-0400

=== Xamarin.iOS ===

Version: 13.16.0.13 (Visual Studio Community)
Hash: b75deaf82
Branch: d16-5-xcode11.4
Build date: 2020-04-01 21:33:19-0400

=== Xamarin Designer ===

Version: 16.5.0.471
Hash: 35aa4889d
Branch: remotes/origin/d16-5
Build date: 2020-02-25 00:52:08 UTC

=== Xamarin.Android ===

Version: 10.2.0.100 (Visual Studio Community)
Commit: xamarin-android/d16-5/988c811
Android SDK: /Users/yadusurf/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
7.0 (API level 24)
7.1 (API level 25)
8.1 (API level 27)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 28.0.2
SDK Build Tools Version: 28.0.3

Build Information:
Mono: c0c5c78
Java.Interop: xamarin/java.interop/d16-5@fc18c54
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@46204c4
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-5@9f4ed4b

=== Microsoft Mobile OpenJDK ===

Java SDK: /Users/yadusurf/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android SDK Manager ===

Version: 16.5.0.39
Hash: 6fb4c79
Branch: remotes/origin/d16-5
Build date: 2020-04-15 20:49:08 UTC

=== Android Device Manager ===

Version: 16.5.0.71
Hash: 49194e8
Branch: remotes/origin/d16-5~1
Build date: 2020-04-15 20:49:28 UTC

=== Xamarin Inspector ===

Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1

=== Build Information ===

Release ID: 805040012
Git revision: 7642369422103e19b0b8d29ddc211abf2fd32607
Build date: 2020-04-16 08:55:15-04
Build branch: release-8.5
Xamarin extensions: 7642369422103e19b0b8d29ddc211abf2fd32607

=== Operating System ===

Mac OS X 10.15.4
Darwin 19.4.0 Darwin Kernel Version 19.4.0
Wed Mar 4 22:28:40 PST 2020
root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64

Log File

Logs generated with "diagnostic" mode.
Logs.zip

[brendanzagaeski]

Thanks for the report!

Initial notes for the team

It appears that either (a) the recording step wrote an invalid value into the custom profile or (b) the compilation step read a value incorrectly from the profile:

[aot-compiler stdout] Using profile data file 'custom.aprof'
[aot-compiler stdout] 41
[aot-compiler stdout] * Assertion: should not be reached at /Users/builder/jenkins/workspace/archive-mono/2019-10/android/release/mono/mini/aot-compiler.c:12437

Assertion at: https://github.com/mono/mono/blob/c0c5c78e2bdbdbf7a70ae10b0a698708f1f2edbe/mono/mini/aot-compiler.c#L12437

[IainS1986]

@brendanzagaeski Hi Brendan, I'm running into this issue too. I previosuly commented on issue #4152 , and sorry in advance for taking a while to get back. I got side tracked with other work and have just returned to try out custom profiles again to see if changes in Xamarin.Android have fixed anything.

I no longer get any DLLs AOTing fine like I did in #4152 , instead I now get what this issue is referring too with the 'Assertion: Should not be reached'

I get the following print outs

[aot-compiler stdout] Mono Ahead of Time compiler - compiling assembly /Users/xxx/Dev/xxx/src/xxx.Droid/obj/Release/android/assets/shrunk/Microsoft.AppCenter.Crashes.Android.Bindings.dll
[aot-compiler stdout] AOTID 529E1A46-C2CC-C258-19B1-BC0E2EA748F6
[aot-compiler stdout] Using profile data file '/Users/xxx/Dev/xxx/src/xxx.Droid/custom.aprof'
[aot-compiler stdout] 62
[aot-compiler stdout] * Assertion: should not be reached at /Users/builder/jenkins/workspace/archive-mono/2020-02/android/release/mono/mini/aot-compiler.c:12556
[aot-compiler stdout]

These print out the same 62 and assertion line for several DLLs and then errors print stating the DLL failed to AOT. I also posted a Question in the Xamarin forums https://forums.xamarin.com/discussion/184970/aot-assertion-should-not-be-reached-issue-using-custom-aot-profile-what-am-i-doing-wrong/p1?new=1

Is there any information I can pass on to you to help in anyway?

[IainS1986]

Inspecting the custom profile gives the (probably expected) error..

Unhandled Exception:
System.NotImplementedException: 62
  at Mono.Profiler.Aot.ProfileReader.ReadAllData (System.IO.Stream stream) [0x002c6] in <f4d316cdb782466a9eaed7b932d8ba25>:0 
  at aotprofiletool.MainClass.Main (System.String[] args) [0x000c5] in <760466f08cbf46d488c659de1f35f29d>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.NotImplementedException: 62
  at Mono.Profiler.Aot.ProfileReader.ReadAllData (System.IO.Stream stream) [0x002c6] in <f4d316cdb782466a9eaed7b932d8ba25>:0 
  at aotprofiletool.MainClass.Main (System.String[] args) [0x000c5] in <760466f08cbf46d488c659de1f35f29d>:0 

[rdavisau]

I think one problem (possibly 'the problem') is the one I found here, where some string lengths are not correctly written to the profile, causing it to be unreadable. Unfortunately, it is beyond my knowledge to get the change I made to be used during the standard profiling flow (msbuild /t: BuildAndStartAotProfiling). Instead, I painstakingly went through my profile and corrected string lengths until I got something that could be read by ProfileReader and friends (including aotcompiler.c during build). Although the profile was readable I'm not sure that guarantees that I fixed all the issues with it; but based on my understanding of the problem I would expect it to then be usable.

With the corrected profile, I was able to build an apk with profiled aot, but when attempting to launch the app, it crashed somewhere early in startup (but after some of my application logic had run). So I went back to the profile and completely removed all the entries related to the problem assemblies - including the assembly entries themselves - and with that final profile I was able to produce a build that launched on device. That might imply that I didn't quite fix the profile the first time, despite making it readable; or it could be that there are changes required somewhere else to support profiled aot and 'odd characters'. My money is on the former though.

In summary, assemblies with types/members that contain 'odd characters' (characters with string.length < encoded byte length, which might come from obfuscation, etc.) can cause the profiler to write unreadable profiles. If you remove references to those items from your profile (or from the startup path of your app), you might be able to get a usable profile.

[jpobst]

With support for Classic Xamarin.Android ended May 1st, 2024, this issue is likely no longer relevant.

If this still persists in .NET 8+, please open a new issue with updated information based on net8.0-android or greater. Please include a link to this issue for context.