Skip to content
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

GREF logging is broken in multi-process apps #1

Open
jonpryor opened this issue Apr 7, 2016 · 0 comments
Open

GREF logging is broken in multi-process apps #1

jonpryor opened this issue Apr 7, 2016 · 0 comments
Assignees
Labels
Area: App Runtime Issues in `libmonodroid.so`.

Comments

@jonpryor
Copy link
Member

jonpryor commented Apr 7, 2016

Scenario: Create a Xamarin.Android app, add a e.g. Service, and set ServiceAttribute.Process:

[Service(Process="example")]
public class MyService : Android.App.Service {
    // ...
}

The problem is that the debug.mono.log system property is read at process startup -- for both (all) processes, the "normal" one and the "example" one, and they don't know to cooperate with each other.

The result is that they each write to grefs.txt, corrupting the contents.

@jonpryor jonpryor added the Area: App Runtime Issues in `libmonodroid.so`. label Dec 4, 2017
dellis1972 pushed a commit that referenced this issue Feb 14, 2018
Fixes: #1296

Xamarin.Android attempts to expose the Java-based Android API as a
".NET feeling" API. This takes many forms, such as prefixing interface
names with `I`, mapping `get` and `set` methods to properties, mapping
listener interfaces to events, and PascalCasing method names.

This also affects Java package names and C# namespaces.

When creating the `.apk` file, we philosophically need to go the
opposite direction: PascalCased members need to be mapped to
"something appropriate" within Java. For example, many Android
Resource ids *must* be all lowercase, and Android doesn't support
package names starting with an uppercase letter in all circumstances.

At one point, we tried mapping C# PascalCased namespaces to camelCased
namespaces, so e.g. `MyExampleNamespace` became the
`myExampleNamesapce` Java package within Java Callable Wrappers.

This turned out to be a Terrible Mistake, particularly on
case-sensitive filesystems, as if casing was *inconsistent*
(`MyExampleNamespace` vs `MyExamplenamespace`), files might not be
packaged.

By Mono for Android 1.0, we settled on just lowercasing the namespace
name to produce Java package names within Android Callable Wrappers.

This was not without it's own problems; in particular, the assembly
name wasn't involved, so if the "same" type (namespace + type) were
present in two different assemblies and we needed to generate Android
Callable Wrappers, they'd "collide," the build would fail, and we'd
have some unhappy customers.

This was later addressed in Xamarin.Android 5.1 by changing the Java
package name generation algorithm to be an MD5SUM of the assembly name
and namespace name, thus allowing types to have assembly identity.
(This was not without its own problems.)

Then it gets slightly more complicated: Android allows type names to
appear in various locations, such as in layout View XML. These don't
allow "just" using the type name; the package name is required for
types outside the `android.widget` Java package.

Initially, we did nothing, so developers had to directly use the
Android Callable Wrapper names:

	<myexamplenamespace.MyCustomCSharpView android:id="@+id/yay_csharp" .../>
	<fragment android:name="myexamplenamespace.MyCustomCSharpFragment" ... />

With the change in Xamarin.Android 5.1, *this couldn't work*; those
types didn't exist anymore.

To square this circle, we processed the resource files to "fixup"
identifiers and replace them with the actual Android Callable Wrapper
names. We'd replace any/all of:

	MyExampleNamespace.MyCustomCSharpView                           // Full name
	MyExampleNamespace.MyCustomCSharpView, MyAssembly               // Partial assembly-qualified name
	MyExampleNamespace.MyCustomCSharpView, MyAssembly, Version=...  // Full assembly qualified name
	myexamplenamespace.MyCustomCSharpView                           // compatibility name

with the appropriate md5'd Android Callable Wrapper name.

Brilliant as this was, there was a problem: [Bug #61073][61073].
If the assembly had a wildcard in the assembly version:

[61073]: https://bugzilla.xamarin.com/show_bug.cgi?id=61073

	[assembly: AssemblyVersion ("1.0.0.*")]

then the "Full assembly qualified name" value would change on *every
build*, which had numerious unintended knock-on effects.

This was fixed in commit e5b1c92, which worked largely by just
killing the Full assembly qualified name version entirely.
Xamarin.Android doesn't support embedding two different versions of
the same assembly, so this was considered to be fine.

...except for one compatibility case: `<fragment/>`s can contain
~arbitrary strings, and we support replacing the entire Full assembly
qualified name within them:

	<fragment
	    android:name="MyExampleNamespace.MyCustomCSharpFragment, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
			...
	/>

However, in a post e5b1c92 world, the above now fails to load on the
device, because it's *not* being appropriately fixed up!

	FATAL EXCEPTION: main
	Process: Mono.Samples.HelloTests, PID: 22977
	java.lang.RuntimeException: Unable to start activity ComponentInfo{Mono.Samples.HelloTests/mono.samples.HelloApp}: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment
		...
	Caused by: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment
	Caused by: android.view.InflateException: Binary XML file line #1: Error inflating class fragment
	Caused by: android.app.Fragment$InstantiationException: Unable to instantiate fragment Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null: make sure class name exists, is public, and has an empty constructor that is public
		...
	Caused by: java.lang.ClassNotFoundException: Didn't find class "Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" on path: DexPathList[[zip file "/data/app/Mono.Samples.HelloTests-1/base.apk"],nativeLibraryDirectories=[/data/app/Mono.Samples.HelloTests-1/lib/arm64, /system/fake-libs64, /data/app/Mono.Samples.HelloTests-1/base.apk!/lib/arm64-v8a, /system/lib64, /vendor/lib64]]
		...

The problem is that what Android "sees" *should* be

	<fragment
	    android:name="md5whatever.MyCustomCSharpFragment"
			...
	/>

where `md5whatever.MyCustomCSharpFragment` *is* a valid Java type that
Android is able to load successfully, but because of e5b1c92 this
replacement was removed.

The fix: simplify the Full assembly-qualified name case to an already
supported example. If the `//fragment/@android:name` value contains a
`,`, assume it's an assembly qualified name and compute the Full name
from it, by stripping off the comma and everything after it, then use
the Full name to lookup the correct Android Callable Wrapper type.
baulig pushed a commit that referenced this issue Feb 21, 2018
commit d3ad544
Author: Dean Ellis <[email protected]>
Date:   Wed Feb 21 16:36:10 2018 +0000

    [Xamarin.Android.Build.Tasks] Update `CalculateProjectDependencies` to match spec (#1323)

    The `GetAndroidDependencies` target (f9b2c97) is intended to be
    called by an IDE on project-load, so that the IDE can install project
    dependencies "in the background," and ideally have the dependencies
    installed before the project is actually built.

    As such, the semantics of the `@(AndroidDependency)` output item
    group need to be agreed upon by xamarin-android, the IDEs, and
    whatever the IDEs use to actually install the dependencies. The
    `%(AndroidDependency.Identity)` values need to be well-defined
    and consistent across these three different libraries.

    In commit f9b2c97, certain values would have a version number
    "embedded" within `%(AndroidDependency.Identity)`, using a `;` to
    separate the name from the version, e.g. `build-tools;26.0.1`.
    Use of `;` was chosen because that made it easier for the package
    installation code to use (e.g. it would be identical to what the
    Android SDK `sdkmanager` utility expects).

    Unfortunately, the use of `;` was counter to the [spec][spec], and
    also looks "weird" in the context of MSBuild, as `;` is *also* the
    item group separator.

    Change the version separator to instead be a `/`. This "looks" better
    and is also consistent with the [installer manifest][manifest] schema
    that we will use, wherein `%(AndroidDependency.Identity)` matches a
    `//xamarin-android/*/@filesystem-path` attribute value:

    	<xamarin-android sdk-version="0.0.0" generated-on="Tue, 20 Feb 2018 21:16:01 GMT">
    	  <platform-tools filesystem-path="platform-tools" path="platform-tools" revision="27.0.1" manifest-url="https://dl.google.com/android/repository/repository2-1.xml" description="Android SDK Platform-Tools" obsolete="False" preview="False" license="android-sdk-license" original-type="generic:genericDetailsType">
    	    <!-- ... -->
    	  </platform-tools>
    	  <build-tool filesystem-path="build-tools/27.0.3" path="build-tools;27.0.3" revision="27.0.3" manifest-url="https://dl.google.com/android/repository/repository2-1.xml" description="Android SDK Build-Tools 27.0.3" obsolete="False" preview="False" license="android-sdk-license" original-type="generic:genericDetailsType">
    	  </build-tool>
    	  <!-- ... -->
    	</xamarin-android>

    `@(AndroidDependency)` could be equivalent to:

    	<ItemGroup>
    	  <AndroidDependency Include="build-tools/27.0.3">
    	    <Version>27.0.3</Version>
    	  </AndroidDependency>
    	  <AndroidDependency Include="platform-tools">
    	    <Version>$(AndroidSdkPlatformToolsVersion)</Version>
    	  </AndroidDependency>
    	  <AndroidDependency Include="platforms/android-27">
    	    <Version>27</Version>
    	  </AndroidDependency>
    	  <AndroidDependency Include="tools">
    	    <Version>$(AndroidSdkToolsVersion)</Version>
    	  </AndroidDependency>
    	</ItemGroup>

    [manifest]: https://gist.github.com/dellis1972/08ba76cc19cdce3dec89c68684664299
    [spec]: https://microsoft-my.sharepoint.com/:w:/r/personal/mhutch_microsoft_com/_layouts/15/WopiFrame.aspx?sourcedoc=%7B0436dd38-c9ff-4cf2-b33c-ee4515b68546%7D&action=edit&wdPid=64869a58

commit e489aae
Author: Jonathan Pryor <[email protected]>
Date:   Wed Feb 21 10:41:32 2018 -0500

    Bump to mono/2017-12/de4729fa (#1325)

    Context: #1078
    Context: mono/mono#7145

    The primary impetus is that mono/de4729fa contains "ignore"
    improvements to `mono-api-html`, which will be needed in order to
    complete PR #1078.

commit f7b24f7
Author: Dean Ellis <[email protected]>
Date:   Tue Feb 20 16:25:23 2018 +0000

    [Xamarin.Android.Build.Tests] Add tests for <ResolveSdks/> (#1321)

    This commit adds a basic unit test for the `<ResolveSdks/>` task.

commit d207275
Author: Atsushi Eno <[email protected]>
Date:   Tue Feb 20 00:37:10 2018 +0900

    [msbuild] Fix <Import>-ed filename, for case sensitivity. (#1322)

    There is a trivial difference between `msbuild` and `xbuild` - `msbuild`
    seems to respect (or ignorant of) the fact that filenames that are different
    in case are actually different on case-sensitive filesystem.

    Thus with `msbuild`, our binding projects don't build due to "missing"
    Microsoft.CSharp.Targets (there are only Microsoft.CSharp.targets even in
    `xbuild` support files in mono).

    This trivial fix should make it work.

commit 49ecdda
Author: Ludovic Henry <[email protected]>
Date:   Fri Feb 16 17:09:43 2018 -0500

    Bump to mono/2017-12/0d51a806 (#1318)

    To simplify integrating mono's SDKs feature.

commit 8419f81
Author: Jonathan Pryor <[email protected]>
Date:   Fri Feb 16 16:07:12 2018 -0500

    Bump $(ProductVersion) to 8.3.99

    (Commercial) Xamarin.Android v8.3 is being tracked in the
    [xamarin-android/d15-7][0] branch, which was branched from
    commit 70ccc83.

    Bump `$(ProductVersion)` to 8.3.99 to track development progress of
    the *next* version of Xamarin.Android.

    [0]: https://github.com/xamarin/xamarin-android/commits/d15-7

commit 70ccc83
Author: Matt Sylvia <[email protected]>
Date:   Fri Feb 16 11:56:35 2018 -0500

    Bump to Java.Interop/master/15cf8c1, mono/2017-12/fbc4f05 (#1317)

    Context: mono/mono#6948

    Harmonizes on cecil/mono-2017-12/dfee11e.

commit c960a6f
Author: Jonathan Pryor <[email protected]>
Date:   Fri Feb 16 10:43:11 2018 -0500

    Bump to xamarin-android-api-compatibility/d15-7/dc5f0c2e

    Fixes an [ABI break][0] in 72ef39b:

    [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/877/

    	<h3>Type Changed: Microsoft.SqlServer.Server.SqlDataRecord</h3>
    	<p>Removed method:</p>
    	<pre>
    	  <span class='removed removed-method breaking' data-is-breaking>public virtual System.Data.IDataReader GetData (int);</span>
    	</pre>

    	<h3>Type Changed: System.Data.SqlClient.SqlConnectionStringBuilder</h3>
    	<p>Removed property:</p>
    	<pre>
    	  <span class='removed removed-property breaking' data-is-breaking>public bool IsFixedSize { get; }</span>
    	</pre>

    	</div> <!-- end type SqlConnectionStringBuilder -->
    	<!-- start type SqlParameterCollection --> <div>
    	<h3>Type Changed: System.Data.SqlClient.SqlParameterCollection</h3>
    	<p>Removed properties:</p>
    	<pre>
    	  <span class='removed removed-property breaking' data-is-breaking>public bool IsFixedSize { get; }</span>
    	  <span class='removed removed-property breaking' data-is-breaking>public bool IsReadOnly { get; }</span>
    	  <span class='removed removed-property breaking' data-is-breaking>public bool IsSynchronized { get; }</span>
    	</pre>

    This doesn't fix the "ABI break"; there is no ABI break of consequence.
    This fixes the *reporting* of the ABI break.

    See also: xamarin/xamarin-android-api-compatibility@5be4d43

commit 72ef39b
Author: Jonathan Pryor <[email protected]>
Date:   Thu Feb 15 20:32:20 2018 -0500

    Bump to xamarin-android-api-compatibility/d15-7/9d71e200

    Context: #1303

    Fixes an [ABI BREAK][0] from b2ca17a:

    	<h3>Type Changed: Android.Widget.ListView</h3>
    	<p>Modified fields:</p>
    	<pre>
    	<div data-is-breaking>	public const <span class='removed removed-inline removed-breaking-inline'>int</span> <span class='added '>ChoiceMode</span> ChoiceModeMultiple = 2;
    	</div><div data-is-breaking>	public const <span class='removed removed-inline removed-breaking-inline'>int</span> <span class='added '>ChoiceMode</span> ChoiceModeNone = 0;
    	</div><div data-is-breaking>	public const <span class='removed removed-inline removed-breaking-inline'>int</span> <span class='added '>ChoiceMode</span> ChoiceModeSingle = 1;
    	</div></pre>

    The problem is that [xamarin-android-api-compatibility PR #13][ac-13]
    is part of PR #1303, but #1303 hasn't been merged yet. As such, it had
    no need to be in the xamarin-android-api-compatibility/d15-7 branch.

    It has been reverted, thus fixing the above ABI break.

    [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/876/console
    [ac-13]: xamarin/xamarin-android-api-compatibility#13

commit d0cb3ce
Author: Jonathan Pryor <[email protected]>
Date:   Thu Feb 15 14:12:30 2018 -0500

    Bump to mono/2017-12/2ad3f0bf

    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60088

commit b2ca17a
Author: Jonathan Pryor <[email protected]>
Date:   Thu Feb 15 12:38:12 2018 -0500

    Bump to xamarin-android-api-compatibility/d15-7/10df9b67 (#1314)

    Context: 34f437d
    Context: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/873/

    The bump to mono/2017-12 in commit 34f437d included ABI "breakage" in
    `System.Data.dll` which wasn't *actual* breakage.

    Update xamarin-android-api-compatibility to so that we don't report
    warnings for this "breakage."

commit 3a35c00
Author: Jonathan Pryor <[email protected]>
Date:   Thu Feb 15 12:36:24 2018 -0500

    Bump to Java.Interop/master/0841c32f

    Bumps to cecil/master/dfee11e

    For d15-7 harmonization.

commit 92949f4
Author: Jonathan Pryor <[email protected]>
Date:   Thu Feb 15 12:27:55 2018 -0500

    [mono-runtimes] Fix bundle usage

    Commit 34f437d inadvertently broke mono bundle usage. For example,
    the [first commit after the mono bump][xa-01be] *should* have taken
    around 3h to build. Instead, it took nearly 7h, because the bundle
    wasn't being used, causing the mono runtimes to be rebuilt:

    [xa-01be]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android/874/

    	Target _BuildUnlessCached needs to be built as output file
    	'…/xamarin-android//bin/Debug/lib/xamarin.android//../../bcl-tests/System.Runtime.CompilerServices.Unsafe.pdb'
    	does not exist.

    Indeed, `System.Runtime.CompilerServices.Usafe.pdb` *doesn't* exist,
    nor should it, as it's compiled from IL directly.

    Fix mono bundle usage by updating `@(_BclTestAssemblyDestination)` to
    exclude `System.Runtime.CompilerServices.Unsafe.pdb`. This allows the
    `_BuildUnlessCached` target to properly recognize that all required
    files *do* exist, thus skipping the mono-runtimes build (as desired).

commit 01be8ac
Author: Dean Ellis <[email protected]>
Date:   Thu Feb 15 02:38:56 2018 +0000

    [Xamarin.Android.Build.Tasks] Stop designtime designer being deleted. (#1307)

    Fixes: #1286

    We have a number of problems with our DesignTime build system. The
    main one which this PR addresses is the designer file is deleted
    by `IncrementalClean` AND `CoreClean`. This them completely messes
    up the DesignTime system since it can no longer find the file.

    So what we should be doing is making sure we don't tell the build
    system about the designer file ;-). We do this by not writing the
    path to the `$(CleanFile)`.

    ~~ Some background on the [DesignTime build system][2] ~~

    The primary entry point is the `CoreCompile` target, with occasional
    calls to the `RefreshReferences` target. In theory
    [`$(DesignTimeBuild)`][1] should be set to `true`; however, this is
    not always the case which is why we have the `_SetupForDesignTimeBuild`
    target which hooks into the `CoreCompile` target. Additionally,
    `$(BuildingProject)` should be False. ([Additional information][2]).
    However this document is not seem to be 100% accurate since the IDE's
    (namely Visual Studio) do not always set the required properties. One
    of the key requirements for design time builds seems to be that they
    are independent of the main builds. The files it uses should not be
    removed since the `CoreCompile` target does not seem to be called
    consistently. For example, if the designer file is removed and the
    `RefreshReferences` target is called, the design time build may well
    fail because the targets required to re-generate the designer file
    are not called.

    Now for the problem: the `IncrementalClean` target runs between builds.
    It seems to want to remove files from the previous build. I suspect the
    purpose is to remove files that are no longer needed. (For example an
    assembly which is no longer referenced.) The problem is that we have
    a file (the design time `Resource.designer.cs`) which is not built as
    part of the normal build. But this file was still being written to
    `$(CleanFile)` which is the driver for the `IncrementalClean` process.
    As a result, the file gets removed because its not in the list of
    current `@(FileWrites)`. Not writing the name of this file to
    `$(CleanFile)` seems to hide it from `IncrementalClean`.

    There was also another problem with the `CoreClean` target. This was
    also removing the designer files. Again this was down to the fact
    that the file was listed in `$(CleanFile)`. However our older
    workarounds did not work since they relied on `IncrementalClean`
    running. For a `Clean` target invocation it does not. Again the
    solution seems to be Don't Write the file to `$(CleanFile)`, which is
    counterintuitive since we are told to write all files we generate to
    that file.

    [1]:  https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md#determining-whether-a-target-is-run-in-a-design-time-build
    [2]: https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md

commit 34f437d
Author: Ludovic Henry <[email protected]>
Date:   Wed Feb 14 14:05:02 2018 -0500

    Bump to mono/2017-12/a0af42ab (#1263)

    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=6339
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=6401
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=8477
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=19503
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=20562
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=31507
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=35661
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=40699
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=45893
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=49308
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=52675
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=53296
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56003
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56194
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=57893
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=57938
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58261
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58400
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58411
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=58965
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59080
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59182
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59364
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59393
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59608
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59664
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59881
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59909
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59913
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59916
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59953
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59956
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=59967
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60028
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60029
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60115
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60175
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60216
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60224
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60233
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60238
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60245
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60255
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60267
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60288
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60298
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60317
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60340
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60422
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60435
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60505
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60514
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60539
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60545
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60634
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60680
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60771
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60860
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60865
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=60973
    Context: https://bugzilla.xamarin.com/show_bug.cgi?id=61002

    Bump minimum macOS Mono version to 5.10.0.47.

commit f279ad3
Author: Dean Ellis <[email protected]>
Date:   Wed Feb 14 15:04:45 2018 +0000

    [Xamarin.Android.Build.Tasks] GetAndroidDependencies calls _SetLatestTargetFrameworkVersion (#1305)

    This is a bug in the `GetAndroidDependencies` target: it does not
    cause `MonoAndroidHelper.RefreshSupportedVersions()` to be invoked.
    As a result if called directly it will generate a
    `NullReferenceException` as `MonoAndroidHelper.SupportedVersions`
    will be `null`.

    The `GetAndroidDependencies` should thus depend upon the
    `_SetLatestTargetFrameworkVersion` target. This will initialize
    `MonoAndroidHelper.SupportedVersions`, and will also resolve the
    correct `$(TargetFrameworkVersion)` if the user has
    `$(AndroidUseLatestPlatformSdk)`=True.

commit 0dee27d
Author: Jonathan Pryor <[email protected]>
Date:   Wed Feb 14 05:50:23 2018 -0500

    [Xamarin.Android.Build.Tasks] Fragments & Shorter acw-map (#1301)

    Fixes: #1296

    Xamarin.Android attempts to expose the Java-based Android API as a
    ".NET feeling" API. This takes many forms, such as prefixing interface
    names with `I`, mapping `get` and `set` methods to properties, mapping
    listener interfaces to events, and PascalCasing method names.

    This also affects Java package names and C# namespaces.

    When creating the `.apk` file, we philosophically need to go the
    opposite direction: PascalCased members need to be mapped to
    "something appropriate" within Java. For example, many Android
    Resource ids *must* be all lowercase, and Android doesn't support
    package names starting with an uppercase letter in all circumstances.

    At one point, we tried mapping C# PascalCased namespaces to camelCased
    namespaces, so e.g. `MyExampleNamespace` became the
    `myExampleNamesapce` Java package within Java Callable Wrappers.

    This turned out to be a Terrible Mistake, particularly on
    case-sensitive filesystems, as if casing was *inconsistent*
    (`MyExampleNamespace` vs `MyExamplenamespace`), files might not be
    packaged.

    By Mono for Android 1.0, we settled on just lowercasing the namespace
    name to produce Java package names within Android Callable Wrappers.

    This was not without it's own problems; in particular, the assembly
    name wasn't involved, so if the "same" type (namespace + type) were
    present in two different assemblies and we needed to generate Android
    Callable Wrappers, they'd "collide," the build would fail, and we'd
    have some unhappy customers.

    This was later addressed in Xamarin.Android 5.1 by changing the Java
    package name generation algorithm to be an MD5SUM of the assembly name
    and namespace name, thus allowing types to have assembly identity.
    (This was not without its own problems.)

    Then it gets slightly more complicated: Android allows type names to
    appear in various locations, such as in layout View XML. These don't
    allow "just" using the type name; the package name is required for
    types outside the `android.widget` Java package.

    Initially, we did nothing, so developers had to directly use the
    Android Callable Wrapper names:

    	<myexamplenamespace.MyCustomCSharpView android:id="@+id/yay_csharp" .../>
    	<fragment android:name="myexamplenamespace.MyCustomCSharpFragment" ... />

    With the change in Xamarin.Android 5.1, *this couldn't work*; those
    types didn't exist anymore.

    To square this circle, we processed the resource files to "fixup"
    identifiers and replace them with the actual Android Callable Wrapper
    names. We'd replace any/all of:

    	MyExampleNamespace.MyCustomCSharpView                           // Full name
    	MyExampleNamespace.MyCustomCSharpView, MyAssembly               // Partial assembly-qualified name
    	MyExampleNamespace.MyCustomCSharpView, MyAssembly, Version=...  // Full assembly qualified name
    	myexamplenamespace.MyCustomCSharpView                           // compatibility name

    with the appropriate md5'd Android Callable Wrapper name.

    Brilliant as this was, there was a problem: [Bug #61073][61073].
    If the assembly had a wildcard in the assembly version:

    [61073]: https://bugzilla.xamarin.com/show_bug.cgi?id=61073

    	[assembly: AssemblyVersion ("1.0.0.*")]

    then the "Full assembly qualified name" value would change on *every
    build*, which had numerious unintended knock-on effects.

    This was fixed in commit e5b1c92, which worked largely by just
    killing the Full assembly qualified name version entirely.
    Xamarin.Android doesn't support embedding two different versions of
    the same assembly, so this was considered to be fine.

    ...except for one compatibility case: `<fragment/>`s can contain
    ~arbitrary strings, and we support replacing the entire Full assembly
    qualified name within them:

    	<fragment
    	    android:name="MyExampleNamespace.MyCustomCSharpFragment, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
    			...
    	/>

    However, in a post e5b1c92 world, the above now fails to load on the
    device, because it's *not* being appropriately fixed up!

    	FATAL EXCEPTION: main
    	Process: Mono.Samples.HelloTests, PID: 22977
    	java.lang.RuntimeException: Unable to start activity ComponentInfo{Mono.Samples.HelloTests/mono.samples.HelloApp}: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment
    		...
    	Caused by: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment
    	Caused by: android.view.InflateException: Binary XML file line #1: Error inflating class fragment
    	Caused by: android.app.Fragment$InstantiationException: Unable to instantiate fragment Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null: make sure class name exists, is public, and has an empty constructor that is public
    		...
    	Caused by: java.lang.ClassNotFoundException: Didn't find class "Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" on path: DexPathList[[zip file "/data/app/Mono.Samples.HelloTests-1/base.apk"],nativeLibraryDirectories=[/data/app/Mono.Samples.HelloTests-1/lib/arm64, /system/fake-libs64, /data/app/Mono.Samples.HelloTests-1/base.apk!/lib/arm64-v8a, /system/lib64, /vendor/lib64]]
    		...

    The problem is that what Android "sees" *should* be

    	<fragment
    	    android:name="md5whatever.MyCustomCSharpFragment"
    			...
    	/>

    where `md5whatever.MyCustomCSharpFragment` *is* a valid Java type that
    Android is able to load successfully, but because of e5b1c92 this
    replacement was removed.

    The fix: simplify the Full assembly-qualified name case to an already
    supported example. If the `//fragment/@android:name` value contains a
    `,`, assume it's an assembly qualified name and compute the Full name
    from it, by stripping off the comma and everything after it, then use
    the Full name to lookup the correct Android Callable Wrapper type.

commit 5c46ee3
Author: Jonathan Pryor <[email protected]>
Date:   Wed Feb 14 05:42:22 2018 -0500

    [api-xml-adjuster] Fix rebuilds (#1300)

    Ideally, project rebuilds when nothing has changed should be *fast*.

    `api-xml-adjuster` isn't:

    	$ time (cd build-tools/api-xml-adjuster ; xbuild)
    	real	2m1.084s
    	user	1m55.916s
    	sys	0m8.853s

    	# and the rebuild!
    	$ time (cd build-tools/api-xml-adjuster ; xbuild)
    	real	2m0.824s
    	user	1m56.140s
    	sys	0m8.600s

    A *minimum* two minute+ rebuild -- when *nothing* has changed -- is a
    surefire way to get really annoyed.

    With diagnostic logging, we start to see the culprit:

    	Target _ClassParse needs to be built as input file '@(ApiFileDefinition -> /Volumes/Seagate4TB/work/xamarin-android/build-tools/api-xml-adjuster/../../src/Mono.Android/Profiles/api-27.params.txt)' does not exist.

    This in turn causes `class-parse.exe` and `api-xml-adjuster.exe` to be
    *re-executed* on *every* `android.jar` on *every* build.

    Fix this by correcting the `//Target/@Inputs` and `//Target/@Outputs`
    for the `_ClassParse` and `_AdjustApiXml` tasks. After which,
    no-change rebuilds are *significantly* faster:

    	$ time (cd build-tools/api-xml-adjuster ; xbuild)
    	real	0m5.308s
    	user	0m6.042s
    	sys	0m1.237s

commit 20b4190
Author: Peter Collins <[email protected]>
Date:   Tue Feb 13 12:53:26 2018 -0500

    [BCL-Tests] Remove '-s' from _GrantPermissions (#1299)

    The [semantics of the `$(AdbTarget)` property][adb-target] are the
    same as the [`adb` Target Device option][adb], which permits any of:

    [adb-target]: Documentation/build_process.md
    [adb]: https://developer.android.com/studio/command-line/adb.html#issuingcommands

      * `-d`: Only attached *device*.
      * `-e`: Only attached *emulator*
      * `-s SERIAL_NUMBER`: A specifically named target; needed if there
        is more than one attached device or emulator.

    The problem with commit c4e8165 is that it overrode the
    `$(InstallDependsOnTargets)` property to call the `_GrantPermissions`
    target, which doesn't properly use `$(AdbTarget)`; it instead
    *requires* using the `-s` option, which is inconsistent:

    	adb -s $(AdbTarget) shell pm grant ...

    Remove `-s` from the `adb` invocation so that `$(AdbTarget)` can
    contain e.g. `-d` or `-e`, as is intended & documented.

commit a4ed574
Author: Dean Ellis <[email protected]>
Date:   Tue Feb 13 16:04:44 2018 +0000

    [Xamarin.Android.Build.Tasks] Only report `ndk-bundle` if required. (#1298)

    We should only list `ndk-bundle` in the `@(AndroidDependencies)` if
    the user is using AOT or MkBundle. Otherwise we will end up
    downloading a ton of stuff we don't need.

    This commit fixes the `CalculateProjectDependencies` to report
    `ndk-bundle` if needed. It also adds a unit test to make sure
    it is not included when it shouldn't be.

commit cb68bc3
Author: Jonathan Pryor <[email protected]>
Date:   Mon Feb 12 17:58:59 2018 -0500

    Bump to Java.Interop/master/10647a5e (#1295)

    Fixes the `ObjectDisposedException` during process shutdown described
    in commit 0a9d164.

    Moves the `ManagedPeer.Init()` invocation within the `JniRuntime`
    constructor so that a `NullReferenceException` is avoided. (Instead, a
    *different*, more meaningful exception should be thrown.)

    Bumps to cecil/mono-2017-12/1afa0668 for d15-7 harmonization.

commit f9b2c97
Author: Dean Ellis <[email protected]>
Date:   Mon Feb 12 16:20:35 2018 +0000

    [Xamarin.Android.Build.Tasks] Add GetAndroidDependencies Target (#1290)

    Fixes: #1269

    This commit adds the `GetAndroidDependencies` target to the
    `Xamarin.Android.Common.targets`. Its purpose is to examine the
    various settings in the project and report which Android SDK
    build-tools, platform-tools, etc. are required.

    `GetAndroidDependencies` will output an `@(AndroidDependency)` with
    `%(AndroidDependency.Version)` metadata.

    `@(AndroidDependency)` will contain `%(Identity)` values of:

      * `build-tools;{VERSION}`, where `{VERSION}` and `%(Version)` is
         controlled by the `$(AndroidSdkBuildToolsVersion)` property.
      * `ndk-bundle`: `%(Version)` is controlled by the
        `$(AndroidNdkVersion)` property.
      * `platform-tools`: `%(Version)` is controlled by the
        `$(AndroidSdkPlatformToolsVersion)` property.
      * `platforms;android-{API}`, where `{API}` and `%(Version)` is the
        API level for the `$(TargetFrameworkVersion)` in the `.csproj`.
        For example, `platforms;android-27` for
        `$(TargetFrameworkVersion)`=`v7.1`.
      * `tools`: `%(Version)` is controlled by the
        `$(AndroidSdkToolsVersion)` property.

commit 0d822e2
Author: Jonathan Pryor <[email protected]>
Date:   Mon Feb 12 10:39:48 2018 -0500

    [Xamarin.Android.Build.Tasks] Improve `javac -version` parsing (#1292)

    The [Ubuntu build][0] is [failing][1]:

    	warning : Failed to get the Java SDK version as it does not appear to contain a valid version number.
    	`javac -version` returned:
    	```openjdk version "1.8.0_03-Ubuntu"
    	OpenJDK Runtime Environment (build 1.8.0_03-Ubuntu-8u77-b03-3ubuntu3-b03)
    	OpenJDK 64-Bit Server VM (build 25.03-b03, mixed mode)
    	```
    	...
    	Task "AdjustJavacVersionArguments"
    	  …/bin/Debug/lib/xamarin.android/xbuild/Xamarin/Android/Xamarin.Android.Common.targets:
    	  error : Error executing task AdjustJavacVersionArguments: Required property 'JdkVersion' not set.

    [0]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-linux/779/
    [1]: https://jenkins.mono-project.com/view/Xamarin.Android/job/xamarin-android-linux/779/consoleText

    This was introduced/broken by commit 0e1d1c8, which turned
    `AdjustJavacVersionArguments.JdkVersion` into a `[Required]`
    parameter. The value for `AdjustJavacVersionArguments.JdkVersion`
    comes from the `<ResolveSdks/>` task `JdkVersion` output parameter,
    which itself comes from parsing `javac -version` output.

    The problem is that the regex we used to parse the output of
    `javac -version` wasn't properly parsing the output on Ubuntu:

    	openjdk version "1.8.0_03-Ubuntu"

    Specifically, the `-Ubuntu` text was causing the regex to not match.

    Update the regex to be a bit more lenient, enabling it to work with
    the Ubuntu `javac -version` output, which *should* allow the build to
    progress further.

commit 0114586
Author: Jonathan Peppers <[email protected]>
Date:   Sun Feb 11 12:53:52 2018 -0600

    [build] fix api-xml-adjuster.targets on Windows (#1291)

    Since 7d705bf, the Windows builds on VSTS have seemed to be failing. I
    tested this locally, and noticed the use of command line arguments such
    as:

        -parameter-names='%(SomeVariable)'

    Unfortunately, this isn't working on Windows due to the single quote. It
    is more appropriately expressed as:

        -parameter-names=&quot;%(SomeVariable)&quot;

    This isn't very pretty, but it should work on all platforms.

    I also fixed all the tabs I saw in this file--in favor of spaces, and
    fixed other XML code conventions.

    I will now return to my regularly scheduled baby duty.
radical pushed a commit that referenced this issue May 8, 2018
The JNI reference count assertions in
JniRuntime.JniObjectReferenceManager were "off," in that the values
they were asserting didn't actually make sense.

Previous logic for JNI local reference create + destroy:

	// Assume localReferenceCount starts at 0, because of course it does
	Assert (localReferenceCount >= 0);  // True; 0 >= 0
	localReferenceCount++;              // localReferenceCount == 1
	...
	Assert (localReferenceCount >= 0);  // True; 1 >= 0
	localReferenceCount--;              // localReferenceCount == 0

The problem with this logic is that it doesn't actually make sense;
when localReferenceCount is incremented to 1, there is one reference
in existence; conceptually, then, the created reference *is* #1.

Meanwhile, at *cleanup*, we first check that localReferenceCount is
valid, *before* we decrement it. We're not validating that e.g.
reference "#1" has been destroyed, or that the number of outstanding
references *after* cleanup is identical to what existed *before* it
was created.

In short, the "dispose" check is in the wrong place. It should be done
*after* decrementing the count, not before:

	Assert (localReferenceCount >= 0);  // True; 0 >= 0
	localReferenceCount++;              // localReferenceCount == 1
	...
	localReferenceCount--;              // localReferenceCount == 0
	Assert (localReferenceCount >= 0);  // True; 0 >= 0

This dovetails nicely with LoggingJniObjectReferenceManagerDecorator
behavior, in that the logging should follow the same pattern as the
count updating: log after create, before delete. If/when reference
lifetimes are entirely nested and not overlapping, this allows for
lrefc value "1" on create to have the same lrefc value "1" on destroy.
radical pushed a commit that referenced this issue May 8, 2018
When `JniRuntime.CreationOptions.DestroyRuntimeOnDispose` is true,
`JavaVM::DestroyJavaVM()` will be invoked when the `JniRuntime`
instance is disposed *or* finalized.

`JreRuntime.CreateJreVM()` would *always* set
`DestroyRuntimeOnDispose` to true, because it called
`JNI_CreateJavaVM()`, so *of course* you'd want to destroy the
Java VM, right?

Which brings us to unit tests. I don't know of any "before all test
fixtures run" and "after all test fixtures run" extension points,
which means:

1. The JVM needs to be created implicitly, "on demand."
2. There's no good way to destroy the JVM created in (1) after all
    tests have finished executing.

Which *really* means that the `JreRuntime` instance is *finalized*,
which sets us up for the unholy trifecta of AppDomain unloads,
finalizers, and JVM shutdown:

For unknown reasons, ~randomly, when running the unit tests (e.g.
`make run-tests`), the test runner will *hang*, indefinitely.

Attaching `lldb` and triggering a backtrace shows the unholy trifecta:

Finalization:

	thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  ...
	  frame #10: 0x00000001001ccb4a mono64`mono_gc_run_finalize(obj=<unavailable>, data=<unavailable>) + 938 at gc.c:256 [opt]
	  frame #11: 0x00000001001cdd4a mono64`finalizer_thread [inlined] finalize_domain_objects + 51 at gc.c:681 [opt]
	  frame #12: 0x00000001001cdd17 mono64`finalizer_thread(unused=<unavailable>) + 295 at gc.c:730 [opt]

JVM destruction:

	thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame #2: 0x000000010ba5bc76 libjvm.dylib`os::PlatformEvent::park() + 192
	  frame #3: 0x000000010ba38e32 libjvm.dylib`ParkCommon(ParkEvent*, long) + 42
	  frame #4: 0x000000010ba39708 libjvm.dylib`Monitor::IWait(Thread*, long) + 168
	  frame #5: 0x000000010ba398f0 libjvm.dylib`Monitor::wait(bool, long, bool) + 246
	  frame #6: 0x000000010bb3dca2 libjvm.dylib`Threads::destroy_vm() + 80
	  frame #7: 0x000000010b8fd665 libjvm.dylib`jni_DestroyJavaVM + 254

AppDomain unload:

	thread #37: tid = 0x4038fb, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
	  frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
	  frame #2: 0x0000000100234a7f mono64`mono_os_cond_timedwait [inlined] mono_os_cond_wait(cond=0x0000000102016e50, mutex=0x0000000102016e10) + 11 at mono-os-mutex.h:105 [opt]
	  frame #3: 0x0000000100234a74 mono64`mono_os_cond_timedwait(cond=0x0000000102016e50, mutex=0x0000000102016e10, timeout_ms=<unavailable>) + 164 at mono-os-mutex.h:120 [opt]
	  frame #4: 0x0000000100234828 mono64`_wapi_handle_timedwait_signal_handle(handle=0x0000000000000440, timeout=4294967295, alertable=1, poll=<unavailable>, alerted=0x0000700000a286f4) + 536 at handles.c:1554 [opt]
	  frame #5: 0x0000000100246370 mono64`wapi_WaitForSingleObjectEx(handle=<unavailable>, timeout=<unavailable>, alertable=<unavailable>) + 592 at wait.c:189 [opt]
	  frame #6: 0x00000001001c832e mono64`mono_domain_try_unload [inlined] guarded_wait(timeout=4294967295, alertable=1) + 30 at appdomain.c:2390 [opt]
	  frame #7: 0x00000001001c8310 mono64`mono_domain_try_unload(domain=0x000000010127ccb0, exc=0x0000700000a287a0) + 416 at appdomain.c:2482 [opt]
	  frame #8: 0x00000001001c7db2 mono64`ves_icall_System_AppDomain_InternalUnload [inlined] mono_domain_unload(domain=<unavailable>) + 20 at appdomain.c:2379 [opt]
	  frame #9: 0x00000001001c7d9e mono64`ves_icall_System_AppDomain_InternalUnload(domain_id=<unavailable>) + 46 at appdomain.c:2039 [opt]

This randomly results in deadlock, and hung Jenkins bots.

Fix this behavior by altering `JreRuntime.CreateJreVM()` to *not*
override the value of
`JniRuntime.CreationOptions.DestroyRuntimeOnDispose`. This allows the
constructor of the `JreRuntime` instance to decide whether or not the
JVM is destroyed.

In the case of TestJVM, we *don't* want to destroy the JVM.

This prevents the JVM from being destroyed, which in turn prevents the
hang during process shutdown.
dellis1972 referenced this issue in dellis1972/xamarin-android May 23, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Jun 18, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Jun 29, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Jul 5, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Jul 17, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Jul 18, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
grendello referenced this issue in grendello/xamarin-android Jul 18, 2018
Xamarin.Android uses the ILRepack
task (https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task/) to repack/merge
the `Xamarin.Android.Build.Tasks` assembly, a step that is performed after the
`Xamarin.Android.Build.Tasks` project build completes. The step takes the
project's output assembly and several other dependencies and merges them into
one, replacing the original output assembly. For the majority of time it works
flawlessly, however the scenario described below causes a Mono runtime
crash (similar to this one mono/mono#9613, although
not identical).

The crash causes aren't yet know in every detail, but the high level overview of
the issue is as follows. Mono runtime uses the `mmap(2)` system call on Unix to
map the on-disk image of the assembly into memory. The mmapped area is used
whenever the same assembly is loaded (e.g. via `Assembly.LoadFrom`) into the
application to save time and memory. The memory is mapped as private which means
that anything written to the mapped area by the Mono process is effectively
discarded, that is not reflected in the file on disk. The protection, however,
doesn't work in the other direction - when an external process (or even the same
Mono process) writes to the file that was mmapped. Unfortunately, the OS kernel
behavior in such instance is left undefined by the POSIX standard - the kernel
can choose to reflect the on-disk change in the mapping or ignore it. On macOS
the write is ignored, on Linux, however, the write leads either to the SIGBUS
signal being sent to the process or corruption to the mmapped memory
area (details of how this happens are, as of yet, unknown - it's just a theory
at this point). The problem occurs in our case when the `ILRepacker` task
overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its
merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping
of that assembly, eventually leading to a segfault:

  #0  0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  #1  0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
  #2  0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
  #3  0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
  dotnet#4  0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
  dotnet#5  <signal handler called>
  dotnet#6  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
  dotnet#7  0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
  dotnet#8  0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
  dotnet#9  0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
  dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
  dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
  dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
  dotnet#13 0x00000000412f4007 in ?? ()
  dotnet#14 0x00007f97440e1918 in ?? ()
  dotnet#15 0x00007f9749bd1800 in ?? ()
  dotnet#16 0x00000000e36e75af in ?? ()
  dotnet#17 0x00007f974434fda8 in ?? ()
  dotnet#18 0x00007f9749bd18e0 in ?? ()
  dotnet#19 0x00007f96e0002820 in ?? ()
  dotnet#20 0x00007f9712164160 in ?? ()
  dotnet#21 0x00007f9712164010 in ?? ()
  dotnet#22 0x0000000000000000 in ?? ()

The crash occurs in frame 7, because the `r` parameter (an instance of the
`MonoAssembly` structure) contains pointers that used to point to valid places
in the `Xamarin.Android.Build.Tasks` assembbly's mmaped area, but now point to
garbage data. One of those corrupted pointers is the ASCII assembly name - which
is used by the function in frame 7.

The situation can be detected by the runtime by using advisory locks and
reporting the attempt to overwrite the mmapped area, however a fix would require
creating a copy of all the assembly's in-memory data before the write is allowed
and that might be too expensive. None of those measures are currently
implemented by Mono (and it isn't sure if any of them will ever be implemented).

The crash this commit fixes occurs in a very specific scenario - when building
the `OpenTK.csproj` project *directly* (that is passing it as parameter to
`msbuild`), which causes a the `Xamarin.Android.Build.Tasks` assembly to be
loaded for use in the `<UsingTask/>` msbuild statement, but at the same time
`OpenTK.csproj` references the `Xamarin.Android.Build.Tasks` *project* which
causes the ILRepacker task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.

The fix, courtesy of @jonpryor, is to make the ILRepacker target not run every
time but only whenver the assembly has to be re-packed because it has just been
rebuilt.
grendello referenced this issue in grendello/xamarin-android Jul 19, 2018
Xamarin.Android uses the ILRepack
task (https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task/) to repack/merge
the `Xamarin.Android.Build.Tasks` assembly, a step that is performed after the
`Xamarin.Android.Build.Tasks` project build completes. The step takes the
project's output assembly and several other dependencies and merges them into
one, replacing the original output assembly. For the majority of time it works
flawlessly, however the scenario described below causes a Mono runtime
crash (similar to this one mono/mono#9613, although
not identical).

The crash causes aren't yet know in every detail, but the high level overview of
the issue is as follows. Mono runtime uses the `mmap(2)` system call on Unix to
map the on-disk image of the assembly into memory. The mmapped area is used
whenever the same assembly is loaded (e.g. via `Assembly.LoadFrom`) into the
application to save time and memory. The memory is mapped as private which means
that anything written to the mapped area by the Mono process is effectively
discarded, that is not reflected in the file on disk. The protection, however,
doesn't work in the other direction - when an external process (or even the same
Mono process) writes to the file that was mmapped. Unfortunately, the OS kernel
behavior in such instance is left undefined by the POSIX standard - the kernel
can choose to reflect the on-disk change in the mapping or ignore it. On macOS
the write is ignored, on Linux, however, the write leads either to the SIGBUS
signal being sent to the process or corruption to the mmapped memory
area (details of how this happens are, as of yet, unknown - it's just a theory
at this point). The problem occurs in our case when the `ILRepacker` task
overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its
merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping
of that assembly, eventually leading to a segfault:

  #0  0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  #1  0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
  #2  0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
  #3  0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
  dotnet#4  0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
  dotnet#5  <signal handler called>
  dotnet#6  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
  dotnet#7  0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
  dotnet#8  0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
  dotnet#9  0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
  dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
  dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
  dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
  dotnet#13 0x00000000412f4007 in ?? ()
  dotnet#14 0x00007f97440e1918 in ?? ()
  dotnet#15 0x00007f9749bd1800 in ?? ()
  dotnet#16 0x00000000e36e75af in ?? ()
  dotnet#17 0x00007f974434fda8 in ?? ()
  dotnet#18 0x00007f9749bd18e0 in ?? ()
  dotnet#19 0x00007f96e0002820 in ?? ()
  dotnet#20 0x00007f9712164160 in ?? ()
  dotnet#21 0x00007f9712164010 in ?? ()
  dotnet#22 0x0000000000000000 in ?? ()

The accompanying managed stacktrace looks as follows:

  Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
  at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
  at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes.ScanAssemblyForPublicTypes () [0x00007] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes/<>c__DisplayClass8_0.<GetLoadedTypeByTypeName>b__0 (string) [0x000b4] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Collections.Concurrent.ConcurrentDictionary`2<TKey_REF, TValue_REF>.GetOrAdd (TKey_REF,System.Func`2<TKey_REF, TValue_REF>) [0x00034] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes.GetLoadedTypeByTypeName (string) [0x0003c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Shared.TypeLoader.GetLoadedType (System.Collections.Concurrent.ConcurrentDictionary`2<System.Func`3<System.Type, object, bool>, System.Collections.Concurrent.ConcurrentDictionary`2<Microsoft.Build.Shared.AssemblyLoadInfo, Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes>>,string,Microsoft.Build.Shared.AssemblyLoadInfo) [0x00042] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Shared.TypeLoader.Load (string,Microsoft.Build.Shared.AssemblyLoadInfo) [0x00008] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.AssemblyTaskFactory.InitializeFactory (Microsoft.Build.Shared.AssemblyLoadInfo,string,System.Collections.Generic.IDictionary`2<string, Microsoft.Build.Framework.TaskPropertyInfo>,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,string) [0x00058] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord.GetTaskFactory (Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,string) [0x000b8] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord.CanTaskBeCreatedByFactory (string,string,System.Collections.Generic.IDictionary`2<string, string>,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x0003b] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Execution.TaskRegistry.GetMatchingRegistration (string,System.Collections.Generic.List`1<Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord>,string,System.Collections.Generic.IDictionary`2<string, string>,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x0001a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Execution.TaskRegistry.GetTaskRegistrationRecord (string,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,bool&) [0x00169] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.Execution.TaskRegistry.GetRegisteredTask (string,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x00010] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TaskExecutionHost.FindTaskInRegistry (System.Collections.Generic.IDictionary`2<string, string>) [0x00038] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.FindTask (System.Collections.Generic.IDictionary`2<string, string>) [0x0000b] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19.MoveNext () [0x0011e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
  at Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket (Microsoft.Build.BackEnd.TaskHost,Microsoft.Build.BackEnd.ItemBucket,Microsoft.Build.BackEnd.TaskExecutionMode,System.Collections.Generic.Dictionary`2<string, string>) [0x00048] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18.MoveNext () [0x0016a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
  at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask (Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup) [0x00037] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13.MoveNext () [0x00193] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
  at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask (Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.BackEnd.BuildRequestEntry,Microsoft.Build.BackEnd.ITargetBuilderCallback,Microsoft.Build.Execution.ProjectTargetInstanceChild,Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup,Microsoft.Build.BackEnd.Lookup,System.Threading.CancellationToken) [0x0006c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52.MoveNext () [0x00091] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52> (Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
  at Microsoft.Build.BackEnd.TargetEntry.ProcessBucket (Microsoft.Build.BackEnd.ITaskBuilder,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup,Microsoft.Build.BackEnd.Lookup) [0x00051] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45.MoveNext () [0x002bb] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45> (Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:316
  at Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget (Microsoft.Build.BackEnd.ITaskBuilder,Microsoft.Build.BackEnd.BuildRequestEntry,Microsoft.Build.BackEnd.Logging.ProjectLoggingContext,System.Threading.CancellationToken) [0x00048] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at Microsoft.Build.BackEnd.TargetBuilder/<ProcessTargetStack>d__21.MoveNext () [0x003a5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<System.Threading.Tasks.VoidTaskResult>.TrySetResult (System.Threading.Tasks.VoidTaskResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<System.Threading.Tasks.VoidTaskResult>.SetResult (System.Threading.Tasks.VoidTaskResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<System.Threading.Tasks.VoidTaskResult>.SetResult (System.Threading.Tasks.Task`1<System.Threading.Tasks.VoidTaskResult>) [0x00010] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:636
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.SetResult () [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:378
  at Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45.MoveNext () [0x00720] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52.MoveNext () [0x001d5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13.MoveNext () [0x0021e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18.MoveNext () [0x002be] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19.MoveNext () [0x003e5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<InitializeAndExecuteTask>d__24.MoveNext () [0x0012d] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteInstantiatedTask>d__26.MoveNext () [0x0065e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at Microsoft.Build.BackEnd.MSBuild/<ExecuteInternal>d__76.MoveNext () [0x004dd] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at Microsoft.Build.BackEnd.MSBuild/<BuildProjectsInParallel>d__77.MoveNext () [0x0014a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at Microsoft.Build.BackEnd.MSBuild/<ExecuteTargets>d__80.MoveNext () [0x00713] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<Microsoft.Build.Framework.BuildEngineResult>.TrySetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.Framework.BuildEngineResult>.SetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at Microsoft.Build.BackEnd.TaskHost/<InternalBuildProjects>d__49.MoveNext () [0x0025c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<Microsoft.Build.Framework.BuildEngineResult>.TrySetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.Framework.BuildEngineResult>.SetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
  at Microsoft.Build.BackEnd.TaskHost/<BuildProjectFilesInParallelAsync>d__53.MoveNext () [0x004fb] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.RequestBuilder/<BuildProjects>d__33.MoveNext () [0x00263] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
  at Microsoft.Build.BackEnd.RequestBuilder/<StartNewBuildRequests>d__51.MoveNext () [0x0020e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
  at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
  at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
  at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
  at System.Threading.Tasks.Task`1<int>.TrySetResult (int) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
  at System.Threading.Tasks.TaskCompletionSource`1<int>.TrySetResult (int) [0x00000] in /home/grendel/vc/mono/mono/external/corefx/src/Common/src/CoreLib/System/Threading/Tasks/TaskCompletionSource.cs:274
  at Microsoft.Build.Shared.AwaitExtensions/<>c__DisplayClass7_2.<ToTask>b__0 (object,bool) [0x00038] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
  at System.Threading.RegisteredWaitHandle.DoCallBack (object) [0x00008] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Threading/RegisteredWaitHandle.cs:103
  at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (object) [0x0000d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1308
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
  at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00021] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1285
  at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:858
  at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1213
  at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001f] in <79002cfb0e6e431d8465d6dcea08995e>:0

The crash occurs in frame 7, because the `r` parameter (an instance of the
`MonoAssembly` structure) contains pointers that used to point to valid places
in the `Xamarin.Android.Build.Tasks` assembbly's mmaped area, but now point to
garbage data. One of those corrupted pointers is the ASCII assembly name - which
is used by the function in frame 7.

The situation can be detected by the runtime by using advisory locks and
reporting the attempt to overwrite the mmapped area, however a fix would require
creating a copy of all the assembly's in-memory data before the write is allowed
and that might be too expensive. None of those measures are currently
implemented by Mono (and it isn't sure if any of them will ever be implemented).

The crash this commit fixes occurs in a very specific scenario - when building
the `OpenTK.csproj` project *directly* (that is passing it as parameter to
`msbuild`), which causes a the `Xamarin.Android.Build.Tasks` assembly to be
loaded for use in the `<UsingTask/>` msbuild statement, but at the same time
`OpenTK.csproj` references the `Xamarin.Android.Build.Tasks` *project* which
causes the ILRepacker task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.

The fix, courtesy of @jonpryor, is to make the ILRepacker target not run every
time but only whenver the assembly has to be re-packed because it has just been
rebuilt.
jonpryor pushed a commit that referenced this issue Jul 19, 2018
Xamarin.Android uses the [ILRepack task][0] to repack/merge the
`Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is
performed after the `Xamarin.Android.Build.Tasks.csproj` project's
`Build` target completes.  The step takes the project's output
assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other
dependencies, then merges them into one, *replacing* the original
output assembly.

The majority of time it works flawlessly, however when building the
`monodroid` repo we observe a Mono runtime crash, similar-but-not-
identical to [mono issue 9613][m9613].  Not all details are
understood, but the high level overview of the issue is as follows:
Mono runtime uses the **mmap**(2) system call on Unix to map the
on-disk image of the assembly into memory.  The `mmapp`ed area is
used whenever the same assembly is loaded (e.g.
`Assembly.LoadFrom()`) into the application to save time and memory.
The memory is mapped as private which means that anything written to
the mapped area by the Mono process is effectively discarded, that is
not reflected in the file on disk.  The protection, however, doesn't
work in the other direction: when an external process (or even the
same Mono process!) writes to the file that was `mmapp`ed.
Unfortunately, the OS kernel behavior in such instance is left
undefined by the POSIX standard: the kernel can choose to reflect the
on-disk change in the mapping or ignore it.  On macOS the write is
ignored; on Linux, the write leads either to the `SIGBUS` signal
being sent to the process or corruption to the `mmap`ped memory area
(details of how this happens are, as of yet, unknown; it's just a
theory at this point).  The problem occurs in our case when the
`<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll`
assembly with its merged/repackaged form and that, somehow, corrupts
Mono runtime's memory mapping of that assembly, eventually crashing:

        ## native crash
        #0  0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
        #1  0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
        #2  0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
        #3  0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
        #4  0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
        #5  <signal handler called>
        #6  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
        #7  0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
        #8  0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
        #9  0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
        #10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
        #11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
        #12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
        ...

        ## managed stacktrace
        at <unknown> <0xffffffff>
        at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
        at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
        at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
        at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
        ...

The crash occurs in frame 7, because the `r` parameter (an instance
of the `MonoAssembly` structure) contains pointers that used to point
to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed
area, but now point to garbage data.  One of those corrupted pointers
is the ASCII assembly name - which is used by the function in frame 7.

The crash this commit fixes occurs in a very specific scenario: when
building the `OpenTK.csproj` project *directly*
(e.g. `msbuild OpenTK.csproj`), which causes the
`Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in
the `<UsingTask/>` MSBuild statement, but at the same time 
`OpenTK.csproj` has a `@(ProjectReference)` to
`Xamarin.Android.Build.Tasks.csproj`, which caused the
`<ILRepacker/>` task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.

The fix, courtesy of @jonpryor, is to make the `ILRepacker` target
not run every time but only whenever the assembly has to be re-packed
because it has just been rebuilt.

This also improves rebuild times.

[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
dellis1972 referenced this issue in dellis1972/xamarin-android Jul 31, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Aug 1, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
dellis1972 referenced this issue in dellis1972/xamarin-android Aug 2, 2018
…e fixed up.

Context dotnet#1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`. We do this
by using the `acwmap.txt` file to make known types onto the
`md5` hashed ones. We do this in a case sensitive manner. We
also only support Camel case and lower case type names.

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is highly
probable that typo's will occur. If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up. Instead the user will recieve the
following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

if you are using the control in a number of places this runtime error
does nothing to help track down the problem.

Instead what we should be doing is detecting these issues and emitting
a build error. This will provide the user not only the problem but
also a link to the file causing the probem.

TODO
----

[ ] Fix up the name so it points to the file in `Resources` not `res`
[ ] Add a Unit test.
[ ] Add Error code and document.
jonpryor pushed a commit that referenced this issue Aug 2, 2018
…e fixed up. (#1720)

Context: #1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`.  We do this by
using the `acwmap.txt` file to map known types onto the `md5` hashed
ones.  This is done in a case sensitive manner.  We also only support
identically-cased and lower-cased namespace/package names:

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is possible that
typo's will occur.  If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up, due to the lowercase `l` in `library`.
Instead the user will see the following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView
	---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView
	---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

If the control is used in a number of places this runtime error does
nothing to help track down the problem.

Improve this scenario by detecting these issues and emitting an
XA1002 build error.  This will not only inform the user about the
problem but also provide a link to the file causing the problem.
jonpryor pushed a commit that referenced this issue Aug 3, 2018
Xamarin.Android uses the [ILRepack task][0] to repack/merge the
`Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is
performed after the `Xamarin.Android.Build.Tasks.csproj` project's
`Build` target completes.  The step takes the project's output
assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other
dependencies, then merges them into one, *replacing* the original
output assembly.

The majority of time it works flawlessly, however when building the
`monodroid` repo we observe a Mono runtime crash, similar-but-not-
identical to [mono issue 9613][m9613].  Not all details are
understood, but the high level overview of the issue is as follows:
Mono runtime uses the **mmap**(2) system call on Unix to map the
on-disk image of the assembly into memory.  The `mmapp`ed area is
used whenever the same assembly is loaded (e.g.
`Assembly.LoadFrom()`) into the application to save time and memory.
The memory is mapped as private which means that anything written to
the mapped area by the Mono process is effectively discarded, that is
not reflected in the file on disk.  The protection, however, doesn't
work in the other direction: when an external process (or even the
same Mono process!) writes to the file that was `mmapp`ed.
Unfortunately, the OS kernel behavior in such instance is left
undefined by the POSIX standard: the kernel can choose to reflect the
on-disk change in the mapping or ignore it.  On macOS the write is
ignored; on Linux, the write leads either to the `SIGBUS` signal
being sent to the process or corruption to the `mmap`ped memory area
(details of how this happens are, as of yet, unknown; it's just a
theory at this point).  The problem occurs in our case when the
`<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll`
assembly with its merged/repackaged form and that, somehow, corrupts
Mono runtime's memory mapping of that assembly, eventually crashing:

        ## native crash
        #0  0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
        #1  0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
        #2  0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
        #3  0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
        #4  0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
        #5  <signal handler called>
        #6  __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
        #7  0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
        #8  0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
        #9  0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
        #10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
        #11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
        #12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
        ...

        ## managed stacktrace
        at <unknown> <0xffffffff>
        at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
        at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
        at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
        at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
        ...

The crash occurs in frame 7, because the `r` parameter (an instance
of the `MonoAssembly` structure) contains pointers that used to point
to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed
area, but now point to garbage data.  One of those corrupted pointers
is the ASCII assembly name - which is used by the function in frame 7.

The crash this commit fixes occurs in a very specific scenario: when
building the `OpenTK.csproj` project *directly*
(e.g. `msbuild OpenTK.csproj`), which causes the
`Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in
the `<UsingTask/>` MSBuild statement, but at the same time 
`OpenTK.csproj` has a `@(ProjectReference)` to
`Xamarin.Android.Build.Tasks.csproj`, which caused the
`<ILRepacker/>` task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.

The fix, courtesy of @jonpryor, is to make the `ILRepacker` target
not run every time but only whenever the assembly has to be re-packed
because it has just been rebuilt.

This also improves rebuild times.

[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
jonpryor pushed a commit that referenced this issue Aug 3, 2018
…e fixed up. (#1720)

Context: #1711

When using a custom view within a layout file we replace the
`namespace.classname` with an `md5hash.classname`.  We do this by
using the `acwmap.txt` file to map known types onto the `md5` hashed
ones.  This is done in a case sensitive manner.  We also only support
identically-cased and lower-cased namespace/package names:

	ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView
	classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView

Given that a user is able to type these manually it is possible that
typo's will occur.  If for example a user types

	Classlibrary1.CustomView

this will NOT be fixed up, due to the lowercase `l` in `library`.
Instead the user will see the following error at runtime.

	FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView
	---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView
	---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView"

If the control is used in a number of places this runtime error does
nothing to help track down the problem.

Improve this scenario by detecting these issues and emitting an
XA1002 build error.  This will not only inform the user about the
problem but also provide a link to the file causing the problem.
dellis1972 pushed a commit that referenced this issue Sep 20, 2018
Fixes: #2193

I have been able to reproduce a #deletebinobj bug with the following
steps:
1. `File | New Project | Android App (Xamarin) | Tabbed App`, set
   `Minimum Android Version` to `Android 5.0 (Lollipop)`
2. Build
3. Add a new `TextView` to `Resources\layout\activity_main.axml`, with
   an id of `textView1`
4. Build and Deploy

Get a crash at runtime:

    Android.Views.InflateException: Binary XML file line #1: Error inflating class android.support.design.widget.BottomNavigationView occurred

A `Rebuild` fixes the problem, and the app starts correctly again.

After comparing `obj` directories from before and after, I noticed
`obj\Debug\android\src\android\support\compat\R.java` was missing the
field for `R.id.textView1`!

    public static int textView1=0x7f080091;

This doesn't match the error message we are getting here at all... But
this file is updated by the `_GenerateJavaDesignerForComponent`
MSBuild target. Further research showed that this target was getting
skipped at step no. 4 above, because it was found to be up to date
according to its inputs and outputs.

To verify this was the case, I could delete
`obj\Debug\Component.R.cs.flag` which would also resolve the runtime
exception (instead of a full `Rebuild`).

First, I created a new test:
- `CustomViewAddResourceId` builds a project with
  `<android.support.design.widget.BottomNavigationView />`
- Adds a `textView1` layout, builds again
- Verifies that `obj\Debug\android\src\android\support\compat\R.java`
  contains `textView1`

To fix the problem, I did the following:
- Added `$(_AndroidResgenFlagFile)` as an input to
  `_GenerateJavaDesignerForComponent`, so it will run again when
  `_UpdateAndroidResgen` runs
- Removed
  `AndroidComponentResgenFlagFile="$(_AndroidComponentResgenFlagFile)"`
  from the call to the `<Aapt />` MSBuild task, so it will re-run
  `aapt` and generate `R.java`.

However, things were breaking when `$(AndroidUseAapt2)` was
enabled.

For `aapt2` support I had to:
- Remove `AndroidComponentResgenFlagFile` from the `<Aapt2Link />`
  call
- Set an extra property that the other `<Aapt2Link />` calls are
  already doing:
  `CompiledResourceFlatArchive="$(IntermediateOutputPath)\compiled.flata"`
dellis1972 pushed a commit that referenced this issue Oct 3, 2018
Fixes: #2193

I have been able to reproduce a #deletebinobj bug with the following
steps:
1. `File | New Project | Android App (Xamarin) | Tabbed App`, set
   `Minimum Android Version` to `Android 5.0 (Lollipop)`
2. Build
3. Add a new `TextView` to `Resources\layout\activity_main.axml`, with
   an id of `textView1`
4. Build and Deploy

Get a crash at runtime:

    Android.Views.InflateException: Binary XML file line #1: Error inflating class android.support.design.widget.BottomNavigationView occurred

A `Rebuild` fixes the problem, and the app starts correctly again.

After comparing `obj` directories from before and after, I noticed
`obj\Debug\android\src\android\support\compat\R.java` was missing the
field for `R.id.textView1`!

    public static int textView1=0x7f080091;

This doesn't match the error message we are getting here at all... But
this file is updated by the `_GenerateJavaDesignerForComponent`
MSBuild target. Further research showed that this target was getting
skipped at step no. 4 above, because it was found to be up to date
according to its inputs and outputs.

To verify this was the case, I could delete
`obj\Debug\Component.R.cs.flag` which would also resolve the runtime
exception (instead of a full `Rebuild`).

First, I created a new test:
- `CustomViewAddResourceId` builds a project with
  `<android.support.design.widget.BottomNavigationView />`
- Adds a `textView1` layout, builds again
- Verifies that `obj\Debug\android\src\android\support\compat\R.java`
  contains `textView1`

To fix the problem, I did the following:
- Added `$(_AndroidResgenFlagFile)` as an input to
  `_GenerateJavaDesignerForComponent`, so it will run again when
  `_UpdateAndroidResgen` runs
- Removed
  `AndroidComponentResgenFlagFile="$(_AndroidComponentResgenFlagFile)"`
  from the call to the `<Aapt />` MSBuild task, so it will re-run
  `aapt` and generate `R.java`.

However, things were breaking when `$(AndroidUseAapt2)` was
enabled.

For `aapt2` support I had to:
- Remove `AndroidComponentResgenFlagFile` from the `<Aapt2Link />`
  call
- Set an extra property that the other `<Aapt2Link />` calls are
  already doing:
  `CompiledResourceFlatArchive="$(IntermediateOutputPath)\compiled.flata"`
jonpryor pushed a commit that referenced this issue Feb 10, 2021
Changes: xamarin/NRefactory@0607a4a...495405a

  * xamarin/NRefactory@495405a6: Merge pull request #2 from jpobst/sdk-style
  * xamarin/NRefactory@e4d5997e: Update some project files to SDK-style.
  * xamarin/NRefactory@60ac8e99: Merge pull request #1 from xamarin/cecilPackageReference
  * xamarin/NRefactory@c2c07caa: Switch Cecil reference to PackageReference.

We are working on using `dotnet build` to build `Xamarin.Android.sln`
and `Xamarin.Android-Tests.sln`.  `dotnet build` requires that all
projects be SDK-style short-form projects.

The `tests/MSBuildDeviceIntegration` integration tests use NRefactory
as part of the debugger tests, to ensure that the debugger can attach
to an app on-device.  In order for `tests/MSBuildDeviceIntegration`
to be buildable with `dotnet build`, NRefactory must have SDK-style
`.csproj` files.

Unfortunately, the [icsharpcode/NRefactory][0] repo only contains
"long-form" projects, has been archived, and is now read-only.

Switch to the [xamarin/NRefactory][1] repo, which is *not* archived
and is maintained by the VSMac team, and bump to a commit which
includes xamarin/NRefactory@e4d5997e, which migrates many of the
`.csproj` files to SDK-style short-form projects.

This allows us to continue our `dotnet build` explorations.

[0]: https://github.com/icsharpcode/NRefactory
[1]: https://github.com/xamarin/NRefactory
jonpryor pushed a commit that referenced this issue Feb 18, 2021
…5623)

Context: #5619

It appears that Xamarin.Android application uploaded to
Google Play Console internal Test Track can fail the pre-launch test
because the `MonodroidRuntime::get_java_class_name_for_TypeManager()`
method can sometimes get a `nullptr` Java class name from JNI:

	Build fingerprint: 'google/blueline/blueline:9/PQ3A.190801.002/5670241:user/release-keys'
	Revision: 'MP1.0'
	ABI: 'arm64'
	pid: 15773, tid: 15773, name: com.Myapp  >>> com.Myapp<<<
	signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
	Cause: null pointer dereference
	    x0  0000000000000000  x1  0000000000000000  x2  0000000000000000  x3  00000000000000e1
	    x4  0000000000000000  x5  0000000000000305  x6  0000000000000006  x7  0000000000000010
	    x8  0101010101010101  x9  4adfd1b7ed2e23e2  x10 0000000000430000  x11 000000000000000a
	    x12 0000000000000002  x13 0000000000000001  x14 00000000000000a8  x15 000000000000000a
	    x16 0000007f703f00f8  x17 0000007f7031f290  x18 0000000000000008  x19 0000000000000000
	    x20 0000007eecae0460  x21 0000000000000000  x22 0000000000000000  x23 0000000000000099
	    x24 0000000000000085  x25 0000007eecb30010  x26 0000000000000099  x27 0000000000000000
	    x28 0000007f724255e0  x29 0000007fe01ad010
	    sp  0000007fe01acff0  lr  0000007f7036f3b4  pc  0000007f7031f2a0
	backtrace:
	    #00 pc 000000000001e2a0  /system/lib64/libc.so (strlen+16)
	    #1 pc 000000000006e3b0  /system/lib64/libc.so (strdup+20)
	    #2 pc 000000000000d4e8  /data/app/com.Myapp-1lufsJe3FIZ0YHoEAB08KA==/split_config.arm64_v8a.apk (offset 0x165d000) (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+92)
	    #3 pc 000000000005f6d0  <anonymous:0000007ecc4ac000>

This can happen if either one of the below points is true:

 1. [`java.lang.Class.getName()`][0] returns `nullptr`
    (a nameless class?  This seems unlikely.)
 2. [`JNIEnv::GetStringUTFChars()`][1] returns `nullptr`
    (a memory allocation failure?)

Of these, (2) appears to be most probable; regardless, add appropriate
`nullptr` checks for each of them, failing gracefully instead of
segfaulting.

This is NOT a fix for the original problem as we don't know by what
it is caused but, nevertheless, the `nullptr` check should be there.

[0]: https://developer.android.com/reference/java/lang/Class?hl=en#getName()
[1]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetStringUTFChars
jonpryor pushed a commit that referenced this issue Apr 14, 2021
#5811)

Context: #5838

This reverts commit d13d0f9.

Commit d13d0f9 inadvertently broke the
[`DebuggingTest.ClassLibraryMainLauncherRuns()` unit test][0], when
using a test app which:

 1. Uses .NET 6, which -- because of d13d0f9 -- sets
    `$(AndroidEnablePreloadAssemblies)`=False by default -- with-

 2. A "Debug" build (Fast Deployment enabled), with-

 3. `$(AndroidLinkResources)`=False (the default; see also 9e6ce03),
    and-

 4. launching the app, which

 5. Loads an `Activity` subclass located in an assembly which is
    *not* the "main" App assembly

then the app crashes during process startup:

	android.runtime.JavaProxyThrowable: System.NullReferenceException: Object reference not set to an instance of an object
	    at MyLibrary.MainActivity.OnCreate(Bundle bundle)
	    at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_savedInstanceState)
	    at com.xamarin.classlibrarymainlauncherruns.MainActivity.n_onCreate(Native Method)
	    at com.xamarin.classlibrarymainlauncherruns.MainActivity.onCreate(MainActivity.java:29)

The cause of the crash is that, because not all assemblies are loaded
as part of process startup -- the whole *point* to d13d0f9 and
defaulting `$(AndroidEnablePreloadAssemblies)`=False -- then
[`ResourceIdManager.UpdateIdValues()`][1] isn't able to update all
fields in all `Resource` types to have the values from the app's
`Resource.designer.cs` file.  Consequently, the values *may* be
invalid, and thus the `NullReferenceException`.

As an "immediate" fix is not quickly forthcoming -- though enabling
`$(AndroidLinkResources)`=False *by default* is an "interesting"
solution, with unknown inner dev loop performance implications --
we're reverting commit d13d0f9.

Issue #5838 will track the re-enabling of
`$(AndroidEnablePreloadAssemblies)`=False by default in .NET 6 apps.

~~~

Additionally, update `DebuggingTest.ClassLibraryMainLauncherRuns()`
so that `Resources\layout\foo.xml` contains *valid* layout XML.
It was originally:

	<?xml version="1.0" encoding="utf-8" ?>
	<LinearLayout
	  xmlns:android="http://schemas.android.com/apk/res/android"
	/>

which would crash with:

	Java.Lang.RuntimeException: Unable to start activity ComponentInfo{com.xamarin.classlibrarymainlauncherruns/com.xamarin.classlibrarymainlauncherruns.MainActivity}:
	  android.view.InflateException: Binary XML file line #1 in com.xamarin.classlibrarymainlauncherruns:layout/foo: Binary XML file line #1: You must supply a layout_width attribute.
	---> Android.Views.InflateException: Binary XML file line #1 in com.xamarin.classlibrarymainlauncherruns:layout/foo: Binary XML file line #1: You must supply a layout_width attribute.
	---> Java.Lang.UnsupportedOperationException: Binary XML file line #1: You must supply a layout_width attribute.
	--- End of managed Java.Lang.UnsupportedOperationException stack trace ---
	java.lang.UnsupportedOperationException: Binary XML file line #1: You must supply a layout_width attribute.

because the layout XML was, in fact, invalid, as it wasn't providing
the required `android:layout_width` attribute.

Update `foo.xml` so that it has valid layout XML:

	<?xml version="1.0" encoding="utf-8"?>
	<LinearLayout
	  xmlns:android="http://schemas.android.com/apk/res/android"
	  android:layout_width="fill_parent"
	  android:layout_height="wrap_content"
	/>"

This way we won't be chasing invalid XML going forward.

The above `UnsupportedOperationException` *hid* the
`NullReferenceException` in d13d0f9; the `NullReferenceException`
wasn't visible until after the invalid XML was fixed.

[0]: https://github.com/xamarin/xamarin-android/blob/bf4f4f42af26cdddb46087deed59aae8424f7942/tests/MSBuildDeviceIntegration/Tests/DebuggingTest.cs#L74-L124
[1]: https://github.com/xamarin/xamarin-android/blob/bf4f4f42af26cdddb46087deed59aae8424f7942/src/Mono.Android/Android.Runtime/ResourceIdManager.cs#L9-L31
jonpryor pushed a commit that referenced this issue May 28, 2021
Changes: dotnet/installer@f442964...3ebe0ca
Changes: dotnet/linker@7a5c445...620b243
Changes: dotnet/runtime@6430375...5a26d12

Context: https://github.com/dotnet/sdk/blob/1f544a59270cecb2947e50a01f7056c685b4e319/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L389-L392
Context: #5954 (comment)
Context: #5669 (comment)
 
Updates:
 
  * Microsoft.Dotnet.Sdk.Internal:
    [from 6.0.100-preview.5.21266.3 to 6.0.100-preview.6.21276.2][0]

  * Microsoft.NET.ILLink.Tasks:
    [from 6.0.100-preview.5.21264.1 to 6.0.100-preview.6.21275.1][1]

  * Microsoft.NETCore.App.Ref:
    [from 6.0.0-preview.5.21265.5 to 6.0.0-preview.6.21274.1][2]
 
Update `.apkdesc` files, as `System.Net.Quic.dll` is now included
in the Xamarin.Forms sample.

Fix `azure-pipelines.yaml` so that if (when) the
`Mono.Android.NET_Tests` unit tests fail, the corresponding `.apk`
or `.aab` file is uploaded for our later investigation; see also
commit af7f7f5, which contained a "typo" such that .NET 6 packages
*weren't* uploaded on unit test failure, as they used the wrong
target framework identifier in the path.

Finally, and most annoying of all, the `$(InvariantGlobalization)`
MSBuild property should *not* default to `false` in .NET 6 projects,
as was introduced in commit 9ac280c, but instead should default
to *the empty string*.

The problem is due to [`Microsoft.NET.Sdk.targets`][3]:

	<RuntimeHostConfigurationOption
	    Condition=" '$(InvariantGlobalization)' != '' "
	    Include="System.Globalization.Invariant"
	    Value="$(InvariantGlobalization)"
	    Trim="true"
	/>

The above fragment sets `%(RuntimeHostConfigurationOption.Trim)` to
`True` for `System.Globalization.Invariant` whenever
`$(InvariantGlobalization)` is *not* the empty string.

The value `false` is *not* the empty string.

This caused `System.Globalization.Invariant`-related trim features
to be enabled, which had the unfortunate and unanticipated side effect
of causing ICU to *not* be properly initialized when running the
`Mono.Android.NET_Tests` unit test apps, which resulted in a SIGSEGV:

	libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 31880 (droid.NET_Tests), pid 31880 (droid.NET_Tests)
	crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	tombstoned: received crash request for pid 31880
	crash_dump64: performing dump of process 31880 (target tid = 31880)
	DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	DEBUG   : Build fingerprint: 'google/redfin/redfin:11/RQ1A.201205.011/6966805:user/release-keys'
	DEBUG   : Revision: 'MP1.0'
	DEBUG   : ABI: 'arm64'
	DEBUG   : Timestamp: 2021-05-26 15:21:42-0400
	DEBUG   : pid: 31880, tid: 31880, name: droid.NET_Tests  >>> Mono.Android.NET_Tests <<<
	DEBUG   : uid: 10282
	DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
	DEBUG   : Cause: null pointer dereference
	DEBUG   :     x0  b400007c4de52530  x1  0000007fcc4cbeec  x2  fffffffffffffff0  x3  b400007d2de37c80
	DEBUG   :     x4  b400007d2de37cf0  x5  0000000000000004  x6  0000007c2225ddac  x7  0000007fcc4cbfe0
	DEBUG   :     x8  0000000000000000  x9  000000001333c921  x10 0000000000000000  x11 000000002de37cf0
	DEBUG   :     x12 000000002a742e66  x13 0000000000000012  x14 0000000000000200  x15 0000000000000011
	DEBUG   :     x16 0000007bd6adb810  x17 0000007ed2056240  x18 0000007ed3b94000  x19 0000007fcc4cc040
	DEBUG   :     x20 b400007c4de52530  x21 b400007c4de52530  x22 0000000000000000  x23 b400007d7de490c0
	DEBUG   :     x24 0000000000000001  x25 0000007bd58055c0  x26 0000007bd5cc0130  x27 0000007ed33ab000
	DEBUG   :     x28 0000007bd6af1000  x29 0000007fcc4cbf00
	DEBUG   :     lr  0000007bd69119c8  sp  0000007fcc4cbee0  pc  0000000000000000  pst 0000000080001000
	…
	DEBUG   : backtrace:
	DEBUG   :       #00 pc 0000000000000000  <unknown>
	DEBUG   :       #1 pc 000000000014e9c4  /data/app/~~oruJhhqj_EC_NWSaIGF_RQ==/Mono.Android.NET_Tests-G1iNxUwmGyu-tDRqYcK94g==/lib/arm64/libmonosgen-2.0.so (GlobalizationNative_GetSortHandle+76) (BuildId: 869ce5526fa884035199acac4ddc81bb6eeaf134)
	DEBUG   :       #2 pc 000000000000ddbc  <anonymous:7c22250000>

While we've (inadvertently) had `%(Trim)` enabled for over three
months now, the *trigger* for this particular crash appears to be
commit dotnet/runtime@bc27d49, which moved ICU initialization outside
of the `GlobalizationMode` static constructor and into a new
`GlobalizationMode.Settings` static constructor…which wasn't executed.

Explicitly setting `$(InvariantGlobalization)` to the empty string
*unless* it is the value `true` allows us to avoid setting
`%(RuntimeHostConfigurationOption.Trim)`=True for
`System.Globalization.Invariant`, which in turn avoids whatever set
of linker-induced changes were preventing ICU from being properly
initialized, which avoids the SIGSEGV.

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Jonathan Peppers <[email protected]>
Co-authored-by: Peter Collins <[email protected]>
 
[0]: dotnet/installer@f442964...3ebe0ca
[1]: dotnet/linker@7a5c445...620b243
[2]: dotnet/runtime@6430375...5a26d12
[3]: https://github.com/dotnet/sdk/blob/1f544a59270cecb2947e50a01f7056c685b4e319/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L389-L392
jonpryor pushed a commit that referenced this issue Aug 26, 2021
Fixes: #6211

Mono VM will return a valid AppDomain pointer (both in "legacy" and
NET6 cases) only if the current thread is attached to some domain.
It is possible that when managed code is called from an unattached
Java thread, `mono_domain_get()` will return `nullptr` instead of a
valid one.  If we further pass `nullptr` to other Mono functions, a
segfault may occur if Mono fails to validate the passed pointer.

Sample code which may trigger the problem:

	public override void OnCreate()
	{
	   AppDomain.CurrentDomain.UnhandledException += (sender, e) => {
	       Console.WriteLine("!!! UnhandledException: " + e.ExceptionObject.GetType().FullName);
	   };
	   base.OnCreate();
	}

	protected override void OnStart()
	{
	    base.OnStart();
	    Java.Util.Concurrent.Executors.NewSingleThreadExecutor()
	        .Execute(new Runnable(() => {
	            throw new Exception("Exception from Java Executor!");
	        }));
	}

Possible crash caused by the above code:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb8 in tid 19241 (pool-1-thread-1), pid 19214 (ndroidcrashtest)
	F DEBUG   : backtrace:
	I hwservicemanager: getTransport: Cannot find entry [email protected]::IMapper/default in either framework or device manifest.
	F DEBUG   :       #00 pc 0011b72f  /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+31) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b)
	F DEBUG   :       #1 pc 0015240d  /data/app/com.companyname.androidcrashtest-sqgk-Mnu8GZM5hKPu1yWEQ==/lib/x86/libmonosgen-2.0.so (mono_domain_assembly_search+61)

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb8 in tid 19763 (pool-1-thread-1), pid 19737 (ndroidcrashtest)
	F DEBUG   : backtrace:
	F DEBUG   :       #00 pc 0011b72f  /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+31) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b)
	F DEBUG   :       #1 pc 0026b91a  /data/app/com.companyname.androidcrashtest-JQoYc3YFwZtEoSJlTqX_BA==/lib/x86/libmonosgen-2.0.so (mono_os_mutex_lock+42)

To avoid the above situation, wrap the `mono_domain_get()` call into
`utils.get_current_domain()` which checks the return value of
`mono_domain_get()` and, if it's `nullptr`, calls
`mono_get_root_domain()` and attaches the current thread to that
root domain.
jonpryor pushed a commit that referenced this issue Oct 29, 2021
Context: #6420 (comment)

Clang's AddressSanitizer detected the following:

	Mono.Android_Tests: ==2488==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x8a600774 at pc 0xaeee9982 bp 0xbf98dc68 sp 0xbf98dc60
	Mono.Android_Tests: WRITE of size 4 at 0x8a600774 thread T0
	Mono.Android_Tests:     #0 0xaeee9981  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)
	Mono.Android_Tests:     #1 0xaeef92d9  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
	Mono.Android_Tests:     #2 0xaef009ae  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
	Mono.Android_Tests:     #3 0xaef06d14  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
	Mono.Android_Tests: 0x8a600774 is located 0 bytes to the right of 4-byte region [0x8a600770,0x8a600774)
	Mono.Android_Tests: allocated by thread T0 here:
	Mono.Android_Tests:     #0 0xaedbe925  (/data/app/Mono.Android_Tests-1/lib/x86/libclang_rt.asan-i686-android.so+0xb6925)
	Mono.Android_Tests:     #1 0xaeee9ae1  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38ae1)
	Mono.Android_Tests:     #2 0xaeee9751  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38751)
	Mono.Android_Tests:     #3 0xaeef92d9  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
	Mono.Android_Tests:     #4 0xaef009ae  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
	Mono.Android_Tests:     #5 0xaef06d14  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
	Mono.Android_Tests:     #6 0xb30cb970  (/data/dalvik-cache/x86/data@[email protected][email protected]@classes.dex+0x5c970)
	Mono.Android_Tests: SUMMARY: AddressSanitizer: heap-buffer-overflow (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)

Address of the offending region points to
`BasicUtilities::monodroid_strsplit()` and is likely the line
modified in this commit.  Append terminating `nullptr` to `vector`
instead of overwriting the last element.
jonpryor pushed a commit that referenced this issue Jan 19, 2022
Commit 6eb11f1 added support for API-32, while keeping the .NET 6
default `$(TargetFramework)` value as `net6.0-android31.0`:

> However, we don't want to change the default API level for .NET 6
> projects; the default will remain `net6.0-android31.0` (API-31),

This appears to have had some unforeseen complications: we would use
the API-31 `Mono.Android.dll`, with the API-32 `libmonodroid.so`/etc.
runtime libraries.  This in turn appears to be responsible for some
crashes we've seen on CI ever since commit c227042 when running the
`Mono.Android.NET_Tests` unit tests under .NET 6 with the interpreter
enabled, because `libxamarin-app.so` and `libmonodroid.so` have ABI
dependencies:

	DOTNET  : JNI_OnLoad: JNI_OnLoad in pal_jni.c
	libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2 in tid 3666 (droid.NET_Tests), pid 3666 (droid.NET_Tests)
	crash_dump64: performing dump of process 3666 (target tid = 3666)
	DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:10/QPP6.190730.005.B1/5775370:userdebug/test-keys'
	DEBUG   : Revision: '0'
	DEBUG   : ABI: 'x86_64'
	DEBUG   : Timestamp: 2022-01-18 16:53:04+0000
	DEBUG   : pid: 3666, tid: 3666, name: droid.NET_Tests  >>> Mono.Android.NET_Tests <<<
	DEBUG   : uid: 10105
	DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2
	DEBUG   : Cause: null pointer dereference
	DEBUG   :     rax 0000000000002b36  rbx 000078c8afb3f860  rcx 000078c98b6561f0  rdx 0000000000000000
	DEBUG   :     r8  0000000000000002  r9  0000000000000080  r10 000078c98b296080  r11 000078c987d35178
	DEBUG   :     r12 00007fffe46ae99c  r13 000078c8afb89ea0  r14 000078c8afb3f990  r15 000078c98b6746c0
	DEBUG   :     rdi 000078c8afb3f860  rsi 0000000000000002
	DEBUG   :     rbp 0000000000000001  rsp 00007fffe46ae448  rip 000078c8afb1b31c
	main    : type=1400 audit(0.0:40): avc: granted { read } for name="u:object_r:net_dns_prop:s0" dev="tmpfs" ino=6642 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:net_dns_prop:s0 tclass=file app=Mono.Android.NET_Tests
	DEBUG   : 
	DEBUG   : backtrace:
	DEBUG   :       #00 pc 000000000002c31c  /data/app/Mono.Android.NET_Tests-fbdZV696v1UeW3jUzJg9yg==/lib/x86_64/libmonodroid.so (xamarin::android::Util::monodroid_store_package_name(char const*)+12) (BuildId: 91fe7d9c6b30356fcfb8337b8541d0132df4f44a)
	DEBUG   :       #1 pc 0000000000025bbc  /data/app/Mono.Android.NET_Tests-fbdZV696v1UeW3jUzJg9yg==/lib/x86_64/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::Java_mono_android_Runtime_initInternal(_JNIEnv*, _jclass*, _jstring*, _jobjectArray*, _jstring*, _jobjectArray*, _jobject*, _jobjectArray*, int, unsigned char, unsigned char)+652) (BuildId: 91fe7d9c6b30356fcfb8337b8541d0132df4f44a)
	DEBUG   :       #2 pc 00000000000273fb  /data/app/Mono.Android.NET_Tests-fbdZV696v1UeW3jUzJg9yg==/lib/x86_64/libmonodroid.so (Java_mono_android_Runtime_initInternal+75) (BuildId: 91fe7d9c6b30356fcfb8337b8541d0132df4f44a)
	DEBUG   :       #3 pc 0000000000174641  /apex/com.android.runtime/lib64/libart.so (art_quick_generic_jni_trampoline+209) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
	…

Thinking about it more, we should only need to use the API-31 "ref"
or "targeting" pack.  The "runtime" pack can just use the latest from
the workload.

To fix this:

 1. Create new `$(_AndroidTargetingPackId)` and
    `$(_AndroidTargetingPackVersion)` properties to use independently
    of the runtime pack version.

 2. Remove `Microsoft.Android.Runtime.31.[rid]` packs from the workload.

 3. Remove the `android-32` workload, as it should no longer be needed.
    The API 31 "ref" pack is fairly small and can go in the `android`
    workload.

Now our `android` workload is:

  * `Microsoft.Android.Sdk`
  * `Microsoft.Android.Ref.31`
  * `Microsoft.Android.Ref.32`
  * `Microsoft.Android.Runtime.32.android-arm`
  * `Microsoft.Android.Runtime.32.android-arm64`
  * `Microsoft.Android.Runtime.32.android-x86`
  * `Microsoft.Android.Runtime.32.android-x64`
  * `Microsoft.Android.Templates`

After these changes, I get this assembly at build time:

	dotnet\packs\Microsoft.Android.Ref.31\31.0.101-preview.11.117\ref\net6.0\Mono.Android.dll

And this assembly at runtime:

	dotnet\packs\Microsoft.Android.Runtime.32.android-arm64\31.0.200-preview.13.21\runtimes\android-arm64\lib\net6.0\Mono.Android.dll

Additionally, CI is fully green; in particular, the
**APKs .NET - macOS** step is green, which hasn't been true on
xamarin-android/main since commit c227042.
jonpryor pushed a commit that referenced this issue Jan 27, 2022
Context: dotnet/maui#4262
Context: #6675

If you run the `maui-blazor` template in a Release build:

	dotnet build -t:Run -c Release

it crashes at runtime:

	D monodroid-assembly: typemap: type with token 33555274 (0x200034a) in module {C7B4CC8F-7A03-4A3F-A34A-DC66EDC548B9} (Mono.Android) corresponds to Java type 'android/runtime/JavaProxyThrowable'
	…
	F DEBUG   : backtrace:
	F DEBUG   : #00 pc 000000000065d8fc  /apex/com.android.art/lib64/libart.so (void art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+156) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #1 pc 000000000069b25d  /apex/com.android.art/lib64/libart.so (art::Thread::GetCurrentMethod(unsigned int*, bool, bool) const+157) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #2 pc 0000000000430fed  /apex/com.android.art/lib64/libart.so (art::JNI<false>::FindClass(_JNIEnv*, char const*)+765) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #3 pc 0000000000047e5a  /data/app/~~0Qm6D1S0sO3f1lwfakN0PA==/com.companyname.mauiapp2-08UokVCH5k_PlbZEH_hhkA==/split_config.x86_64.apk!libmono-android.release.so (offset 0x11e000) (java_interop_jnienv_find_class+26) (BuildId: 3d04f8b946590175e97b89aee2e3b19ceed4b524)
	F DEBUG   : #4 pc 00000000000128ac  <anonymous:41640000>

The crash can be avoided by disabling the linker:

	dotnet build -t:Run -c Release -p:AndroidLinkMode=None
	# -or-
	dotnet build -t:Run -c Release -p:PublishTrimmed=false

However, let us return to the crash: *why* is it crashing?
This isn't a "good debugging experience"; we have no useful context.

Lots of investigation later -- all hail printf debugging -- and we
found that the cause of the crash was an unhandled exception:

 1. `Mono.Android.dll` has it's Java Callable Wrappers generated
    from the *unlinked* assembly, into `mono.android.jar` and
    `mono.android.dex` files.  The Java Callable Wrapper for
    `Android.Runtime.InputStreamAdapter` thus includes *all*
    `Read()` method overloads.

 2. When the app is built in Release configuration, linking is
    enabled, and *some* of the `InputStreamAdapter.Read()` methods
    are removed by the linker, along with the
    `Java.IO.InputStream.Read()` methods that were overridden.

 3. At runtime, we perform [Java Type Registration][0] for the
    `Android.Runtime.InputStreamAdapter` type, which eventually calls
    `AndroidTypeManager.RegisterNativeMembers()`, which eventually
    attempts to *effectively* do:

        Delegate.CreateDelegate (
	        typeof(Func<Delegate>),
	        typeof(InputStreamAdapter),
	        "GetReadHandler");

 4. Because of (2), `Java.IO.InputStream.GetReadHandler()`
    *does not exist*, and thus `Delegate.CreateDelegate()` throws an
    `ArgumentException`.

So far, so reasonable, but…

 5. `AndroidTypeManager.RegisterNativeMembers()` didn't catch any
    exceptions, nor did any other method between the original Java
    `Runtime.register()` invocation and
    `AndroidTypeManager.RegisterNativeMembers()`.  The result is that
    a C# exception was "in flight", and Mono then proceeded to
    *tear down the stack frame* as it unwound the callstack looking
    for `catch` handlers.

At this point, the process is toast: the runtime stack is FUBAR.

This is also why the `backtrace:` is "rooted" in
`JNIEnv::FindClass()`: `JNIEnv::FindClass()` invokes Java static
constructors before returning, which is how the static constructor in
the Java Callable Wrapper for `InputStreamAdapter` called
`Runtime.register()` in the first place.

All of this makes for a miserable debugging experience.

Fixing the "original" linker issue will be done in
#6675.

This hasn't been an issue in "Classic" Xamarin.Android, presumably
because the classic linker isn't as good as the net6 linker.

What we want to do *here* is improve this debugging experience, by
"wrapping" `AndroidTypeManager.RegisterNativeMembers()` in a
`try`/`catch` block, which can then *marshal the thrown exception*
back to Java.  This *prevents* Mono from unwinding the callstack past
a JNI boundary, and avoids the annoying-to-debug app crash.

After this change, we get a much friendlier unhandled exception crash:

	I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable
	I MonoDroid:
	I MonoDroid:   --- End of managed Android.Runtime.JavaProxyThrowable stack trace ---
	I MonoDroid: android.runtime.JavaProxyThrowable: System.ArgumentException: Arg_DlgtTargMeth
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String , Boolean , Boolean )
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String )
	I MonoDroid:    at Android.Runtime.AndroidTypeManager.RegisterNativeMembers(JniType , Type , String )
	I MonoDroid: --- End of stack trace from previous location ---
	I MonoDroid:    at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue[] )
	I MonoDroid:    at Android.Runtime.JNIEnv.FindClass(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.AllocObject(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue[] )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter..ctor(Stream )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter.ToLocalJniHandle(Stream )
	I MonoDroid:    at Android.Webkit.WebResourceResponse..ctor(String , String , Int32 , String , IDictionary`2 , Stream )
	I MonoDroid:    at Microsoft.AspNetCore.Components.WebView.Maui.WebKitWebViewClient.ShouldInterceptRequest(WebView view, IWebResourceRequest request)
	I MonoDroid:    at Android.Webkit.WebViewClient.n_ShouldInterceptRequest_Landroid_webkit_WebView_Landroid_webkit_WebResourceRequest_(IntPtr , IntPtr , IntPtr , IntPtr )
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.n_shouldInterceptRequest(Native Method)
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.shouldInterceptRequest(WebKitWebViewClient.java:39)
	I MonoDroid: 	at Rr.a(chromium-TrichromeWebViewGoogle.apk-stable-410410686:16)
	I MonoDroid: 	at org.chromium.android_webview.AwContentsBackgroundThreadClient.shouldInterceptRequestFromNative(chromium-TrichromeWebViewGoogle.apk-stable-410410686:2)
	I MonoDroid:
	I MonoDroid:   --- End of managed Android.Runtime.JavaProxyThrowable stack trace ---
	I MonoDroid: android.runtime.JavaProxyThrowable: System.ArgumentException: Arg_DlgtTargMeth
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String , Boolean , Boolean )
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String )
	I MonoDroid:    at Android.Runtime.AndroidTypeManager.RegisterNativeMembers(JniType , Type , String )
	I MonoDroid: --- End of stack trace from previous location ---
	I MonoDroid:    at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue[] )
	I MonoDroid:    at Android.Runtime.JNIEnv.FindClass(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.AllocObject(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue[] )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter..ctor(Stream )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter.ToLocalJniHandle(Stream )
	I MonoDroid:    at Android.Webkit.WebResourceResponse..ctor(String , String , Int32 , String , IDictionary`2 , Stream )
	I MonoDroid:    at Microsoft.AspNetCore.Components.WebView.Maui.WebKitWebViewClient.ShouldInterceptRequest(WebView view, IWebResourceRequest request)
	I MonoDroid:    at Android.Webkit.WebViewClient.n_ShouldInterceptRequest_Landroid_webkit_WebView_Landroid_webkit_WebResourceRequest_(IntPtr , IntPtr , IntPtr , IntPtr )
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.n_shouldInterceptRequest(Native Method)
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.shouldInterceptRequest(WebKitWebViewClient.java:39)
	I MonoDroid: 	at Rr.a(chromium-TrichromeWebViewGoogle.apk-stable-410410686:16)
	I MonoDroid: 	at org.chromium.android_webview.AwContentsBackgroundThreadClient.shouldInterceptRequestFromNative(chromium-TrichromeWebViewGoogle.apk-stable-410410686:2)

This is much easier to reason about, and will save us time in
the future.

[0]: https://github.com/xamarin/xamarin-android/wiki/Blueprint#java-type-registration
jonathanpeppers added a commit that referenced this issue Jan 27, 2022
Context: dotnet/maui#4262
Context: #6675

If you run the `maui-blazor` template in a Release build:

	dotnet build -t:Run -c Release

it crashes at runtime:

	D monodroid-assembly: typemap: type with token 33555274 (0x200034a) in module {C7B4CC8F-7A03-4A3F-A34A-DC66EDC548B9} (Mono.Android) corresponds to Java type 'android/runtime/JavaProxyThrowable'
	…
	F DEBUG   : backtrace:
	F DEBUG   : #00 pc 000000000065d8fc  /apex/com.android.art/lib64/libart.so (void art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+156) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #1 pc 000000000069b25d  /apex/com.android.art/lib64/libart.so (art::Thread::GetCurrentMethod(unsigned int*, bool, bool) const+157) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #2 pc 0000000000430fed  /apex/com.android.art/lib64/libart.so (art::JNI<false>::FindClass(_JNIEnv*, char const*)+765) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
	F DEBUG   : #3 pc 0000000000047e5a  /data/app/~~0Qm6D1S0sO3f1lwfakN0PA==/com.companyname.mauiapp2-08UokVCH5k_PlbZEH_hhkA==/split_config.x86_64.apk!libmono-android.release.so (offset 0x11e000) (java_interop_jnienv_find_class+26) (BuildId: 3d04f8b946590175e97b89aee2e3b19ceed4b524)
	F DEBUG   : #4 pc 00000000000128ac  <anonymous:41640000>

The crash can be avoided by disabling the linker:

	dotnet build -t:Run -c Release -p:AndroidLinkMode=None
	# -or-
	dotnet build -t:Run -c Release -p:PublishTrimmed=false

However, let us return to the crash: *why* is it crashing?
This isn't a "good debugging experience"; we have no useful context.

Lots of investigation later -- all hail printf debugging -- and we
found that the cause of the crash was an unhandled exception:

 1. `Mono.Android.dll` has it's Java Callable Wrappers generated
    from the *unlinked* assembly, into `mono.android.jar` and
    `mono.android.dex` files.  The Java Callable Wrapper for
    `Android.Runtime.InputStreamAdapter` thus includes *all*
    `Read()` method overloads.

 2. When the app is built in Release configuration, linking is
    enabled, and *some* of the `InputStreamAdapter.Read()` methods
    are removed by the linker, along with the
    `Java.IO.InputStream.Read()` methods that were overridden.

 3. At runtime, we perform [Java Type Registration][0] for the
    `Android.Runtime.InputStreamAdapter` type, which eventually calls
    `AndroidTypeManager.RegisterNativeMembers()`, which eventually
    attempts to *effectively* do:

        Delegate.CreateDelegate (
	        typeof(Func<Delegate>),
	        typeof(InputStreamAdapter),
	        "GetReadHandler");

 4. Because of (2), `Java.IO.InputStream.GetReadHandler()`
    *does not exist*, and thus `Delegate.CreateDelegate()` throws an
    `ArgumentException`.

So far, so reasonable, but…

 5. `AndroidTypeManager.RegisterNativeMembers()` didn't catch any
    exceptions, nor did any other method between the original Java
    `Runtime.register()` invocation and
    `AndroidTypeManager.RegisterNativeMembers()`.  The result is that
    a C# exception was "in flight", and Mono then proceeded to
    *tear down the stack frame* as it unwound the callstack looking
    for `catch` handlers.

At this point, the process is toast: the runtime stack is FUBAR.

This is also why the `backtrace:` is "rooted" in
`JNIEnv::FindClass()`: `JNIEnv::FindClass()` invokes Java static
constructors before returning, which is how the static constructor in
the Java Callable Wrapper for `InputStreamAdapter` called
`Runtime.register()` in the first place.

All of this makes for a miserable debugging experience.

Fixing the "original" linker issue will be done in
#6675.

This hasn't been an issue in "Classic" Xamarin.Android, presumably
because the classic linker isn't as good as the net6 linker.

What we want to do *here* is improve this debugging experience, by
"wrapping" `AndroidTypeManager.RegisterNativeMembers()` in a
`try`/`catch` block, which can then *marshal the thrown exception*
back to Java.  This *prevents* Mono from unwinding the callstack past
a JNI boundary, and avoids the annoying-to-debug app crash.

After this change, we get a much friendlier unhandled exception crash:

	I MonoDroid: Android.Runtime.JavaProxyThrowable: Exception_WasThrown, Android.Runtime.JavaProxyThrowable
	I MonoDroid:
	I MonoDroid:   --- End of managed Android.Runtime.JavaProxyThrowable stack trace ---
	I MonoDroid: android.runtime.JavaProxyThrowable: System.ArgumentException: Arg_DlgtTargMeth
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String , Boolean , Boolean )
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String )
	I MonoDroid:    at Android.Runtime.AndroidTypeManager.RegisterNativeMembers(JniType , Type , String )
	I MonoDroid: --- End of stack trace from previous location ---
	I MonoDroid:    at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue[] )
	I MonoDroid:    at Android.Runtime.JNIEnv.FindClass(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.AllocObject(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue[] )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter..ctor(Stream )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter.ToLocalJniHandle(Stream )
	I MonoDroid:    at Android.Webkit.WebResourceResponse..ctor(String , String , Int32 , String , IDictionary`2 , Stream )
	I MonoDroid:    at Microsoft.AspNetCore.Components.WebView.Maui.WebKitWebViewClient.ShouldInterceptRequest(WebView view, IWebResourceRequest request)
	I MonoDroid:    at Android.Webkit.WebViewClient.n_ShouldInterceptRequest_Landroid_webkit_WebView_Landroid_webkit_WebResourceRequest_(IntPtr , IntPtr , IntPtr , IntPtr )
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.n_shouldInterceptRequest(Native Method)
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.shouldInterceptRequest(WebKitWebViewClient.java:39)
	I MonoDroid: 	at Rr.a(chromium-TrichromeWebViewGoogle.apk-stable-410410686:16)
	I MonoDroid: 	at org.chromium.android_webview.AwContentsBackgroundThreadClient.shouldInterceptRequestFromNative(chromium-TrichromeWebViewGoogle.apk-stable-410410686:2)
	I MonoDroid:
	I MonoDroid:   --- End of managed Android.Runtime.JavaProxyThrowable stack trace ---
	I MonoDroid: android.runtime.JavaProxyThrowable: System.ArgumentException: Arg_DlgtTargMeth
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String , Boolean , Boolean )
	I MonoDroid:    at System.Delegate.CreateDelegate(Type , Type , String )
	I MonoDroid:    at Android.Runtime.AndroidTypeManager.RegisterNativeMembers(JniType , Type , String )
	I MonoDroid: --- End of stack trace from previous location ---
	I MonoDroid:    at Java.Interop.JniEnvironment.StaticMethods.CallStaticObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.CallStaticObjectMethod(IntPtr , IntPtr , JValue[] )
	I MonoDroid:    at Android.Runtime.JNIEnv.FindClass(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.AllocObject(String )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue* )
	I MonoDroid:    at Android.Runtime.JNIEnv.StartCreateInstance(String , String , JValue[] )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter..ctor(Stream )
	I MonoDroid:    at Android.Runtime.InputStreamAdapter.ToLocalJniHandle(Stream )
	I MonoDroid:    at Android.Webkit.WebResourceResponse..ctor(String , String , Int32 , String , IDictionary`2 , Stream )
	I MonoDroid:    at Microsoft.AspNetCore.Components.WebView.Maui.WebKitWebViewClient.ShouldInterceptRequest(WebView view, IWebResourceRequest request)
	I MonoDroid:    at Android.Webkit.WebViewClient.n_ShouldInterceptRequest_Landroid_webkit_WebView_Landroid_webkit_WebResourceRequest_(IntPtr , IntPtr , IntPtr , IntPtr )
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.n_shouldInterceptRequest(Native Method)
	I MonoDroid: 	at crc64d693e2d9159537db.WebKitWebViewClient.shouldInterceptRequest(WebKitWebViewClient.java:39)
	I MonoDroid: 	at Rr.a(chromium-TrichromeWebViewGoogle.apk-stable-410410686:16)
	I MonoDroid: 	at org.chromium.android_webview.AwContentsBackgroundThreadClient.shouldInterceptRequestFromNative(chromium-TrichromeWebViewGoogle.apk-stable-410410686:2)

This is much easier to reason about, and will save us time in
the future.

[0]: https://github.com/xamarin/xamarin-android/wiki/Blueprint#java-type-registration
jonpryor pushed a commit that referenced this issue May 25, 2022
Context: dotnet/install-scripts#15
Context: https://dot.net/v1/dotnet-install.sh
Context: https://dot.net/v1/dotnet-install.ps1

We've been installing dotnet versions using the [`dotnet-install`][0]
scripts for Unix & Windows.  However, they do not cache the
downloaded archive, and therefore we end up re-downloading the same
archive over and over again.

Additionally, if one finds themselves without an internet connection,
there's no way to easily install the required version of dotnet.

The installation scripts don't provide a way to cache the payloads
and they appear to be in maintenance mode (dotnet/install-scripts#15),
so there doesn't appear to be a chance to add caching support to them.

Fortunately, we can "ask" the scripts what they're downloading:

	% curl -o dotnet-install.sh 'https://dot.net/v1/dotnet-install.sh'
	% ./dotnet-install.sh --version 7.0.100-preview.5.22273.1 --verbose --dry-run  \
	| grep 'dotnet-install: URL'

This returns a list of URLs, which may or may not exist:

	dotnet-install: URL #0 - primary: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz
	dotnet-install: URL #1 - legacy: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz
	dotnet-install: URL #2 - primary: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz
	dotnet-install: URL #3 - legacy: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz

We now parse this output, extract the URLs, then download and cache
the URL contents into `$(AndroidToolchainCacheDirectory)`.

When we need to install .NET, we just extract the cached archive
into the appropriate directory.

If no `dotnet-install: URL…` messages are generated, then we run
the `dotnet-install` script as we previously did.

This process lets us take a first step towards fully "offline" builds,
along with smaller downloads on CI servers.

[0]: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
jonpryor pushed a commit that referenced this issue Jan 26, 2023
…7732)

Fixes: #7335

Context: d236af5

Commit d236af5 introduced embedded assembly compression, using LZ4,
which speeds up startup and reduces final package size.

Assemblies are compressed at build time and, at the same time, pre-
allocated buffers for the **decompressed** data are allocated in
`libxamarin-app.so`.  The buffers are then passed to the LZ4 APIs,
all threads using the same output buffer.  The assumption was that we
can do fine without locking as even if overlapped decompression
happens, the output data will be the same and so even if two threads
do the same thing at the same time, the data will be valid at all
times, so long as at least one thread completes the decompression.

This assumption proved to be **largely** true, but it appears that in
high concurrency cases it is possible that the data in the
decompression buffer differs.  This can result in app crashes:

	A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name)
	A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool  >>> myapp.name <<<
	A/DEBUG:       #1 pc 0000000000029b1c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371)
	A/DEBUG:       #2 pc 00000000002680bc  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #3 pc 00000000002681e8  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #4 pc 000000000008555c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	…

My guess is that LZ4 either uses the output buffer as a scratchpad
area when decompressing or that it initializes/modifies the buffer
before writing actual data in it.  With overlapped decompression, it
may lead to one thread overwriting valid data previously written by
another thread, so that when the latter returns the buffer it thought
to have had valid data may contain certain bytes temporarily
overwritten by the decompression session in the other, still running,
thread.  It may happen that MonoVM reads the corrupted data just when
it is still invalid (before the still running decompression session
actually writes the valid data), a classic race condition.

To fix this, the decompression block is now protected with a startup-
aware mutex.  Mutex will be held only after the initial startup phase
is completed, so there should not be much loss of startup performance.
jonpryor pushed a commit that referenced this issue Jan 28, 2023
…7732)

Fixes: #7335

Context: d236af5

Commit d236af5 introduced embedded assembly compression, using LZ4,
which speeds up startup and reduces final package size.

Assemblies are compressed at build time and, at the same time, pre-
allocated buffers for the **decompressed** data are allocated in
`libxamarin-app.so`.  The buffers are then passed to the LZ4 APIs,
all threads using the same output buffer.  The assumption was that we
can do fine without locking as even if overlapped decompression
happens, the output data will be the same and so even if two threads
do the same thing at the same time, the data will be valid at all
times, so long as at least one thread completes the decompression.

This assumption proved to be **largely** true, but it appears that in
high concurrency cases it is possible that the data in the
decompression buffer differs.  This can result in app crashes:

	A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name)
	A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool  >>> myapp.name <<<
	A/DEBUG:       #1 pc 0000000000029b1c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371)
	A/DEBUG:       #2 pc 00000000002680bc  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #3 pc 00000000002681e8  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #4 pc 000000000008555c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	…

My guess is that LZ4 either uses the output buffer as a scratchpad
area when decompressing or that it initializes/modifies the buffer
before writing actual data in it.  With overlapped decompression, it
may lead to one thread overwriting valid data previously written by
another thread, so that when the latter returns the buffer it thought
to have had valid data may contain certain bytes temporarily
overwritten by the decompression session in the other, still running,
thread.  It may happen that MonoVM reads the corrupted data just when
it is still invalid (before the still running decompression session
actually writes the valid data), a classic race condition.

To fix this, the decompression block is now protected with a startup-
aware mutex.  Mutex will be held only after the initial startup phase
is completed, so there should not be much loss of startup performance.
jonpryor pushed a commit that referenced this issue Feb 27, 2023
…7817)

Fixes: #7335

Context: d236af5

Commit d236af5 introduced embedded assembly compression, using LZ4,
which speeds up startup and reduces final package size.

Assemblies are compressed at build time and, at the same time, pre-
allocated buffers for the **decompressed** data are allocated in
`libxamarin-app.so`.  The buffers are then passed to the LZ4 APIs,
all threads using the same output buffer.  The assumption was that we
can do fine without locking as even if overlapped decompression
happens, the output data will be the same and so even if two threads
do the same thing at the same time, the data will be valid at all
times, so long as at least one thread completes the decompression.

This assumption proved to be **largely** true, but it appears that in
high concurrency cases it is possible that the data in the
decompression buffer differs.  This can result in app crashes:

	A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name)
	A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool  >>> myapp.name <<<
	A/DEBUG:       #1 pc 0000000000029b1c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371)
	A/DEBUG:       #2 pc 00000000002680bc  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #3 pc 00000000002681e8  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	A/DEBUG:       #4 pc 000000000008555c  /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b)
	…

My guess is that LZ4 either uses the output buffer as a scratchpad
area when decompressing or that it initializes/modifies the buffer
before writing actual data in it.  With overlapped decompression, it
may lead to one thread overwriting valid data previously written by
another thread, so that when the latter returns the buffer it thought
to have had valid data may contain certain bytes temporarily
overwritten by the decompression session in the other, still running,
thread.  It may happen that MonoVM reads the corrupted data just when
it is still invalid (before the still running decompression session
actually writes the valid data), a classic race condition.

To fix this, the decompression block is now protected with a startup-
aware mutex.  Mutex will be held only after the initial startup phase
is completed, so there should not be much loss of startup performance.
jonpryor pushed a commit that referenced this issue Jul 13, 2023
Context: 929e701
Context: ce2bc68
Context: #7473
Context: #8155

The managed linker can produce assemblies optimized for the target
`$(RuntimeIdentifier)` (RID), which means that they will differ
between different RIDs.  Our "favorite" example of this is
`IntPtr.Size`, which is inlined by the linker into `4` or `8` when
targeting 32-bit or 64-bit platforms.  (See also #7473 and 929e701.)

Another platform difference may come in the shape of CPU intrinsics
which will change the JIT-generated native code in ways that will
crash the application if the assembler instructions generated for the
intrinsics aren't supported by the underlying processor.

In addition, the per-RID assemblies will have different [MVID][0]s
and **may** have different type and method metadata token IDs, which
is important because typemaps *use* type and metadata token IDs; see
also ce2bc68.

All of this taken together invalidates our previous assumption that
all the managed assemblies are identical.  "Simply" using
`IntPtr.Size` in an assembly that contains `Java.Lang.Object`
subclasses will break things.

This in turn could cause "mysterious" behavior or crashes in Release
applications; see also Issue #8155.

Prevent the potential problems by processing each per-RID assembly
separately and output correct per-RID LLVM IR assembly using the
appropriate per-RID information.

Additionally, during testing I found that for our use of Cecil within
`<GenerateJavaStubs/>` doesn't consistently remove the fields,
delegates, and methods we remove in `MarshalMethodsAssemblyRewriter`
when marshal methods are enabled, or it generates subtly broken
assemblies which cause **some** applications to segfault at run time
like so:

	I monodroid-gc: 1 outstanding GREFs. Performing a full GC!
	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 in tid 12379 (t6.helloandroid), pid 12379 (t6.helloandroid)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'google/raven_beta/raven:14/UPB3.230519.014/10284690:user/release-keys'
	F DEBUG   : Revision: 'MP1.0'
	F DEBUG   : ABI: 'arm64'
	F DEBUG   : Timestamp: 2023-07-04 22:09:58.762982002+0200
	F DEBUG   : Process uptime: 1s
	F DEBUG   : Cmdline: com.microsoft.net6.helloandroid
	F DEBUG   : pid: 12379, tid: 12379, name: t6.helloandroid  >>> com.microsoft.net6.helloandroid <<<
	F DEBUG   : uid: 10288
	F DEBUG   : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000008
	F DEBUG   : Cause: null pointer dereference
	F DEBUG   :     x0  0000000000000000  x1  0000007ba1401af0  x2  00000000000000fa  x3  0000000000000001
	F DEBUG   :     x4  0000007ba1401b38  x5  0000007b9f2a8360  x6  0000000000000000  x7  0000000000000000
	F DEBUG   :     x8  ffffffffffc00000  x9  0000007b9f800000  x10 0000000000000000  x11 0000007ba1400000
	F DEBUG   :     x12 0000000000000000  x13 0000007ba374ad58  x14 0000000000000000  x15 00000013ead77d66
	F DEBUG   :     x16 0000007ba372f210  x17 0000007ebdaa4a80  x18 0000007edf612000  x19 000000000000001f
	F DEBUG   :     x20 0000000000000000  x21 0000007b9f2a8320  x22 0000007b9fb02000  x23 0000000000000018
	F DEBUG   :     x24 0000007ba374ad08  x25 0000000000000004  x26 0000007b9f2a4618  x27 0000000000000000
	F DEBUG   :     x28 ffffffffffffffff  x29 0000007fc592a780
	F DEBUG   :     lr  0000007ba3701f44  sp  0000007fc592a730  pc  0000007ba3701e0c  pst 0000000080001000
	F DEBUG   : 8 total frames
	F DEBUG   : backtrace:
	F DEBUG   :       #00 pc 00000000002d4e0c  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #1 pc 00000000002c29e8  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #2 pc 00000000002c34bc  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #3 pc 00000000002c2254  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #4 pc 00000000002be0bc  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #5 pc 00000000002bf050  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #6 pc 00000000002a53a4  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (mono_gc_collect+44) (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       #7 pc 000000000000513c  <anonymous:7ec716b000>

This is because we generate Java Callable Wrappers over a set of
original (linked or not) assemblies, then we scan them for classes
derived from `Java.Lang.Object` and use that set as input to the
marshal methods rewriter, which makes the changes (generates wrapper
methods, decorates wrapped methods with `[UnmanagedCallersOnly]`,
removes the old delegate methods as well as delegate backing fields)
to all the `Java.Lang.Object` subclasses, then writes the modified
assembly to a `new/<assembly.dll>` location (efa14e2), followed by
copying the newly written assemblies back to the original location.
At this point, we have the results returned by the subclass scanner
in memory and **new** versions of those types on disk, but they are
out of sync, since the types in memory refer to the **old** assemblies,
but AOT is ran on the **new** assemblies which have a different layout,
changed MVIDs and, potentially, different type and method token IDs
(because we added some methods, removed others etc) and thus it causes
the crashes at the run time.  The now invalid set of "old" types is
passed to the typemap generator.  This only worked by accident, because
we (incorrectly) used only the first linked assembly which happened
to be the same one passed to the JLO scanner and AOT - so everything
was fine at the execution time.

Address this by *disabling* LLVM Marshal Methods (8bc7a3e) for .NET 8,
setting `$(AndroidEnableMarshalMethods)`=False by default.
We'll attempt to fix these issues for .NET 9.

[0]: https://learn.microsoft.com/dotnet/api/system.reflection.module.moduleversionid?view=net-7.0
jonpryor added a commit that referenced this issue Jan 26, 2024
Context: dotnet/java-interop@6b3637d

The story so far is that some of our unit tests are crashing, and
have been in one form or another since 4332ea0
(the bump to dotnet/java-interop@def5bc0).

The current crash, from the PR build for 7b46391:

	D monodroid-assembly: typemap: assembly 'Java.Interop-Tests' hasn't been loaded yet, attempting a full load
	W monodroid-assembly: typemap: failed to load managed assembly 'Java.Interop-Tests.dll'. No such file or directory
	E monodroid-assembly: typemap: unable to load assembly 'Java.Interop-Tests' when looking up managed type corresponding to Java type 'java/lang/Object'
	I monodroid-timing: [1/5] Typemap.java_to_managed: end, total time; elapsed: 0:0::260000
	W monodroid-assembly: typemap: called from
	W monodroid-assembly: at Java.Interop.TypeManager.GetJavaToManagedType(String )
	W monodroid-assembly:    at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	W monodroid-assembly:    at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
	W monodroid-assembly:    at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
	W monodroid-assembly:    at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
	W monodroid-assembly:    at Android.Runtime.JavaSet.Iterator()
	W monodroid-assembly:    at Android.Runtime.JavaSet`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].GetEnumerator()
	W monodroid-assembly:    at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].ProcessArguments()
	W monodroid-assembly:    at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].OnCreate(Bundle arguments)
	W monodroid-assembly:    at Android.App.Instrumentation.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_arguments)
	W monodroid-assembly:    at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPL_V(_JniMarshal_PPL_V callback, IntPtr jnienv, IntPtr klazz, IntPtr p0)
	E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x75  (index 7 in a table of size 7)
	F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75

There are *three* "concerning" items here:

 1. typemaps are trying to load `Java.Interop-Tests`, and failing:

        typemap: failed to load managed assembly 'Java.Interop-Tests.dll'. No such file or directory

    @grendello is looking into this.

 2. The binding for `java/lang/Object` is coming from
    Java.Interop-Tests, not Mono.Android (?!)

        typemap: unable to load assembly 'Java.Interop-Tests' when looking up managed type corresponding to Java type 'java/lang/Object'

    dotnet/java-interop#1181 has a fix for this, and we're not
    applying the fix yet because we believe that it will hide (1).

 3. The JNI error, which crashes the process:

        F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75
        F droid.NET_Test: java_vm_ext.cc:570]     from void crc643df67da7b13bb6b1.TestInstrumentation_1.n_onCreate(android.os.Bundle)
        F droid.NET_Test: runtime.cc:630] Runtime aborting...
        F droid.NET_Test: runtime.cc:630] Dumping all threads without mutator lock held
        F droid.NET_Test: runtime.cc:630] All threads:
        F droid.NET_Test: runtime.cc:630] DALVIK THREADS (14):
        F droid.NET_Test: runtime.cc:630] "main" prio=5 tid=1 Runnable
        F droid.NET_Test: runtime.cc:630]   | group="" sCount=0 dsCount=0 flags=0 obj=0x729e9d98 self=0x7567e0f51000
        F droid.NET_Test: runtime.cc:630]   | sysTid=9143 nice=0 cgrp=default sched=0/0 handle=0x7567e14daed8
        F droid.NET_Test: runtime.cc:630]   | state=R schedstat=( 1270418000 334229000 139 ) utm=16 stm=110 core=0 HZ=100
        F droid.NET_Test: runtime.cc:630]   | stack=0x7ffcbb3e4000-0x7ffcbb3e6000 stackSize=8192KB
        F droid.NET_Test: runtime.cc:630]   | held mutexes= "abort lock" "mutator lock"(shared held)
        F droid.NET_Test: runtime.cc:630]   native: #00 pc 000000000048df4e  /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+126)
        F droid.NET_Test: runtime.cc:630]   native: #1 pc 00000000005a77c3  /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool, BacktraceMap*, bool) const+675)
        F droid.NET_Test: runtime.cc:630]   native: #2 pc 00000000005c49cb  /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+859)
        F droid.NET_Test: runtime.cc:630]   native: #3 pc 00000000005bcf28  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+456)
        F droid.NET_Test: runtime.cc:630]   native: #4 pc 00000000005bc2e1  /apex/com.android.runtime/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool)+1601)
        F droid.NET_Test: runtime.cc:630]   native: #5 pc 0000000000552eb9  /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+1529)
        F droid.NET_Test: runtime.cc:630]   native: #6 pc 000000000000c873  /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+611)
        F droid.NET_Test: runtime.cc:630]   native: #7 pc 00000000003ede84  /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1604)
        F droid.NET_Test: runtime.cc:630]   native: #8 pc 00000000003ee18a  /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+234)
        F droid.NET_Test: runtime.cc:630]   native: #9 pc 00000000005adf31  /apex/com.android.runtime/lib64/libart.so (art::Thread::DecodeJObject(_jobject*) const+785)
        F droid.NET_Test: runtime.cc:630]   native: #10 pc 00000000003def9b  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckInstance(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck::InstanceKind, _jobject*, bool)+91)
        F droid.NET_Test: runtime.cc:630]   native: #11 pc 00000000003de205  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+485)
        F droid.NET_Test: runtime.cc:630]   native: #12 pc 00000000003dd732  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+690)
        F droid.NET_Test: runtime.cc:630]   native: #13 pc 00000000003ce865  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)
        F droid.NET_Test: runtime.cc:630]   native: #14 pc 0000000000017196  /data/app/Mono.Android.NET_Tests-LUUW792fOvX745oAS4jeRQ==/split_config.x86_64.apk (offset 331000) (???)
        F droid.NET_Test: runtime.cc:630]   at crc643df67da7b13bb6b1.TestInstrumentation_1.n_onCreate(Native method)

As per `native #13`, we're (somehow) passing an invalid JNI reference
to `JNIEnv::GetObjectClass()`.

***HOW*** are we passing an invalid JNI reference to
`JNIEnv::GetObjectClass()`?

Attempt to investigate (3) further, by:

 1. Reviewing all calls to `JNIEnv::GetObjectClass()` within this
    repo to see if we could potentially be passing an invalid value.
    The "most obvious" candidate is `TypeManager.CreateInstance()`,
    which calls `JNIEnv::GetObjectClass()` in a loop.

    I'm still not sure if that could possibly be the cause, but
    Just In Case™…

    "Cleanup" some C++ code so that calls to
    `JNIEnv::DeleteLocalReference()` are closer to the
    `JNIEnv::GetObjectClass()` calls.

 2. Update
    `tests/Mono.Android-Tests/Runtime-Microsoft.Android.Sdk/Mono.Android.NET-Tests.csproj`
    to add an `@(AndroidEnvironment)` item, which sets
    `debug.mono.log=gref+,lref+`.  This will enable LREF and GREF
    logging within `adb logcat`, which *may* allow us to track down
    where "local reference 0x75" came from.
jonpryor pushed a commit that referenced this issue Mar 20, 2024
Context: 5205a5f
Context: 8a5b2a0
Context: #8724
Context: #8797

As we have solved all trimming warnings (5205a5f. 8a5b2a0) in the
Android workload, we can now go "all in" on trimming.

Early in .NET 6 (maybe even 5?) we "hid" many trimming warnings as we
did not yet plan to solve them:

	<SuppressTrimAnalysisWarnings Condition=" '$(SuppressTrimAnalysisWarnings)' == '' ">true</SuppressTrimAnalysisWarnings>

These warnings were not *actionable* at the time for customers, as
many warnings were in `Mono.Android.dll`, `Java.Interop.dll`, etc.

Going forward, let's stop suppressing these warnings for
`$(TrimMode)`=full.

We can also enable trimming for new projects:

  * `dotnet new android`
  * `dotnet new android-wear`

New projects will have the [`$(TrimMode)`][0] property set to `Full`
by default:

	<!--
	  Enable full trimming in Release mode.
	  To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/trimming-options#trimming-granularity
	-->
	<PropertyGroup Condition="'$(Configuration)' == 'Release'">
	  <TrimMode>full</TrimMode>
	</PropertyGroup>

We wouldn't want to do this for existing projects *yet*, as they
might have existing code, NuGet packages, etc. where trimming
warnings might be present.

We can also improve the templates for Android class libraries:

  * `dotnet new androidlib`
  * `dotnet new android-bindinglib`

New class library projects will have the [`$(IsTrimmable)`][1]
property set to `true` by default:

	<!--
	  Enable trim analyzers for Android class libraries.
	  To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/prepare-libraries-for-trimming
	-->
	<IsTrimmable>true</IsTrimmable>

This way, new class libraries will be "trimmable" by default and be
able to react to trimming warnings.

We can also use `$(TrimMode)=full` in many of our existing tests:

  * MSBuild tests that assert 0 warnings can use `$(TrimMode)=full`.

  * On-device tests can use `$(TrimMode)=full`.


~~ General trimming warnings ~~

This was discovered through `Mono.Android-NET-Tests.csproj`, but
there were a few trimmer warnings in the "layout bindings" feature:

	…\dotnet\packs\Microsoft.Android.Sdk.Windows\…\tools\LayoutBinding.cs(79,56):
	  warning IL2091: Xamarin.Android.Design.LayoutBinding.<>c__DisplayClass8_0<T>.<FindFragment>b__0(Activity):
	  'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicConstructors',
	    'DynamicallyAccessedMemberTypes.NonPublicConstructors' in 'Android.App.FragmentManager.FindFragmentById<T>(Int32)'.
	  The generic parameter 'T' of 'Xamarin.Android.Design.LayoutBinding.<>c__DisplayClass8_0<T>' does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.
	…\dotnet\packs\Microsoft.Android.Sdk.Windows\…\tools\LayoutBinding.cs(35,5):
	  warning IL2091: Xamarin.Android.Design.LayoutBinding.FindView<T>(Int32, T&):
	  'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicConstructors',
	    'DynamicallyAccessedMemberTypes.NonPublicConstructors' in 'Android.App.Activity.FindViewById<T>(Int32)'.
	  The generic parameter 'T' of 'Xamarin.Android.Design.LayoutBinding.FindView<T>(Int32, T&)' does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.
	…\dotnet\packs\Microsoft.Android.Sdk.Windows\…\tools\LayoutBinding.cs(37,5):
	  warning IL2091: Xamarin.Android.Design.LayoutBinding.FindView<T>(Int32, T&):
	  'T' generic argument does not satisfy 'DynamicallyAccessedMemberTypes.PublicConstructors',
	    'DynamicallyAccessedMemberTypes.NonPublicConstructors' in 'Android.Views.View.FindViewById<T>(Int32)'.
	  The generic parameter 'T' of 'Xamarin.Android.Design.LayoutBinding.FindView<T>(Int32, T&)' does not have matching annotations.
	  The source value must declare at least the same requirements as those declared on the target location it is assigned to.

We can `[DynamicallyAccessedMembers(Constructors)]` to fix these.


~~ Trimming warnings in tests ~~

Several tests that verify "trimming unsafe features" just specify:

	[RequiresUnreferencedCode ("Tests trimming unsafe features")]

If the test might have an issue under NativeAOT, I used:

	// FIXME: #8724
	#pragma warning disable IL3050

Places that use `Assembly.GetType()` can use `Type.GetType()` instead:

	-var JavaProxyThrowable_type = typeof (Java.Lang.Object)
	-    .Assembly
	-    .GetType ("Android.Runtime.JavaProxyThrowable");
	+var JavaProxyThrowable_type = Type.GetType ("Android.Runtime.JavaProxyThrowable, Mono.Android");

`SystemTests.AppDomainTest` was just ignored (and had warnings).
Update to just verify `PlatformNotSupportedException` is thrown.


~~ Test failures ~~

`JsonSerializerTest` requires setting
[`$(JsonSerializerIsReflectionEnabledByDefault)`][2]=true:

	<JsonSerializerIsReflectionEnabledByDefault>true</JsonSerializerIsReflectionEnabledByDefault>

Otherwise, an exception is thrown:

	System.InvalidOperationException : JsonSerializerIsReflectionDisabled

`Java.Interop-Tests` were initially not loaded at all, with the log
message:

	W NUnit   : Failed to load tests from assembly 'Java.Interop-Tests, Version=1.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065

If we make `Java.Interop-Tests.dll` a `@(TrimmerRootAssembly)`:

	<TrimmerRootAssembly Include="Java.Interop-Tests" RootMode="All" />

Then all the tests cases are preserved and can be run, in the same
way the "main app assembly" is preserved.

`Android.GraphicsTests.NinePatchTests` failed with:

	The drawable created from resource tile should be a NinePatchDrawable.
	Expected: not null
	But was:  null

The only usage of `NinePatchDrawable` was:

	Assert.IsNotNull (d as NinePatchDrawable);

`NinePatchDrawable` likely needs its interfaces and constructors
preserved for this test to pass.  I added an attribute for just `All`
members for the test to pass:

	[DynamicDependency (DynamicallyAccessedMemberTypes.All, typeof (NinePatchDrawable))]

`Xamarin.Android.RuntimeTests.CustomWidgetTests` failed with:

	(Binary XML file line #1 in Mono.Android.NET_Tests:layout/uppercase_custom: Binary XML file line #1 in Mono.Android.NET_Tests:layout/uppercase_custom: Error inflating class Mono.Android_Test.Library.CustomTextView)
	   at Java.Interop.JniEnvironment.InstanceMethods.CallObjectMethod(JniObjectReference , JniMethodInfo , JniArgumentValue* )
	   at Java.Interop.JniPeerMembers.JniInstanceMethods.InvokeVirtualObjectMethod(String , IJavaPeerable , JniArgumentValue* )
	   at Android.Views.LayoutInflater.Inflate(Int32 , ViewGroup )
	   at Xamarin.Android.RuntimeTests.CustomWidgetTests.<>c.<UpperCaseCustomWidget_ShouldNotThrowInflateException>b__0_0()
	   at NUnit.Framework.Constraints.VoidInvocationDescriptor.Invoke()
	   at NUnit.Framework.Constraints.ExceptionInterceptor.Intercept(Object )
	--- End of managed Java.Lang.RuntimeException stack trace ---
	android.view.InflateException: Binary XML file line #1 in Mono.Android.NET_Tests:layout/uppercase_custom: Binary XML file line #1 in Mono.Android.NET_Tests:layout/uppercase_custom: Error inflating class Mono.Android_Test.Library.CustomTextView
	Caused by: android.view.InflateException: Binary XML file line #1 in Mono.Android.NET_Tests:layout/uppercase_custom: Error inflating class Mono.Android_Test.Library.CustomTextView
	Caused by: java.lang.ClassNotFoundException: Mono.Android_Test.Library.CustomTextView
	   at java.lang.Class.classForName(Native Method)
	   at java.lang.Class.forName(Class.java:454)
	   at android.view.LayoutInflater.createView(LayoutInflater.java:815)
	   at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:1006)
	   at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:961)
	   at android.view.LayoutInflater.rInflate(LayoutInflater.java:1123)
	   at android.view.LayoutInflater.rInflateChildren(LayoutInflater.java:1084)
	   at android.view.LayoutInflater.inflate(LayoutInflater.java:682)
	   at android.view.LayoutInflater.inflate(LayoutInflater.java:534)
	   at android.view.LayoutInflater.inflate(LayoutInflater.java:481)
	   at crc643df67da7b13bb6b1.TestInstrumentation_1.n_onStart(Native Method)
	   at crc643df67da7b13bb6b1.TestInstrumentation_1.onStart(TestInstrumentation_1.java:32)
	   at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:2189)
	Caused by: java.lang.ClassNotFoundException: Didn't find class "Mono.Android_Test.Library.CustomTextView" on path

In this case, `Mono.Android_Test.Library.CustomTextView` was used
from an Android layout, but not used anywhere in managed code.

To fix, I added:

	[DynamicDependency (DynamicallyAccessedMemberTypes.All, typeof (Mono.Android_Test.Library.CustomTextView))]

I could have also made `Mono.Android_Test.Library` a `@(TrimmerRootAssembly)`.

TODO: `View` subclasses used within Android Layout `.axml` files
should be automatically preserved; see #8797.

[0]: https://learn.microsoft.com/dotnet/core/deploying/trimming/trimming-options?pivots=dotnet-8-0#trimming-granularity
[1]: https://learn.microsoft.com/dotnet/core/deploying/trimming/prepare-libraries-for-trimming?pivots=dotnet-8-0#enable-project-specific-trimming
[2]: https://learn.microsoft.com/dotnet/core/compatibility/serialization/8.0/publishtrimmed
jonathanpeppers added a commit that referenced this issue Jul 25, 2024
Context: dotnet/maui#23694 (review)
Context: https://github.com/dotnet/maui/blob/d38ca872f68326ab623c050b0efd93c7d212e000/src/Essentials/test/DeviceTests/Tests/Preferences_Tests.cs#L305-L310
Context: 06bb1dc...45855b8

A .NET MAUI on-device test is crashing on API 23 emulators:

    07-23 11:35:45.837  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115] local reference table dump:
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]   Last 10 entries (of 512):
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       511: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       510: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       509: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       508: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       507: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       506: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       505: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       504: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       503: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       502: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl>
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]   Summary:
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]       511 of java.lang.Class (7 unique instances)
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]         1 of android.app.SharedPreferencesImpl
    07-23 11:35:45.839  4252  4277 F art     : art/runtime/indirect_reference_table.cc:115]
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/barrier.cc:90] Check failed: count_ == 0 (count_=-1, 0=0) Attempted to destroy barrier with non zero count
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/runtime.cc:366] Runtime aborting --- recursively, so no thread-specific detail!
    07-23 11:35:45.930  4252  4277 F art     : art/runtime/runtime.cc:366]
    --------- beginning of crash
    07-23 11:35:45.930  4252  4277 F libc    : Fatal signal 6 (SIGABRT), code -6 in tid 4277 (.NET TP Worker)
    07-23 11:35:46.003  1640  1640 I SELinux : SELinux: Loaded file_contexts contexts from /file_contexts.
    07-23 11:35:46.006  1640  1640 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    07-23 11:35:46.006  1640  1640 F DEBUG   : Build fingerprint: 'Android/sdk_google_phone_x86_64/generic_x86_64:6.0/MASTER/6695544:userdebug/test-keys'
    07-23 11:35:46.006  1640  1640 F DEBUG   : Revision: '0'
    07-23 11:35:46.006  1640  1640 F DEBUG   : ABI: 'x86_64'
    07-23 11:35:46.006  1640  1640 F DEBUG   : pid: 4252, tid: 4277, name: .NET TP Worker  >>> com.microsoft.maui.essentials.devicetests <<<
    07-23 11:35:46.006  1640  1640 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
    07-23 11:35:46.014  1640  1640 F DEBUG   : Abort message: 'art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)'
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rax 0000000000000000  rbx 00007f7dadfbf500  rcx ffffffffffffffff  rdx 0000000000000006
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rsi 00000000000010b5  rdi 000000000000109c
    07-23 11:35:46.014  1640  1640 F DEBUG   :     r8  0000000000000001  r9  0000000000000003  r10 0000000000000008  r11 0000000000000206
    07-23 11:35:46.014  1640  1640 F DEBUG   :     r12 00000000000010b5  r13 0000000000000006  r14 00007f7dc7305a40  r15 00007f7dabd70cc0
    07-23 11:35:46.014  1640  1640 F DEBUG   :     cs  0000000000000033  ss  000000000000002b
    07-23 11:35:46.014  1640  1640 F DEBUG   :     rip 00007f7dcaa49a67  rbp 0000000000000002  rsp 00007f7dadfbc048  eflags 0000000000000206
    07-23 11:35:46.018  1640  1640 F DEBUG   :
    07-23 11:35:46.018  1640  1640 F DEBUG   : backtrace:
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #00 pc 0000000000087a67  /system/lib64/libc.so (tgkill+7)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #1 pc 0000000000085b11  /system/lib64/libc.so (pthread_kill+65)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #2 pc 000000000002e841  /system/lib64/libc.so (raise+17)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #3 pc 00000000000288fd  /system/lib64/libc.so (abort+61)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #4 pc 00000000004ffd65  /system/lib64/libart.so (art::Runtime::Abort()+341)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #5 pc 0000000000178d71  /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #6 pc 0000000000172dad  /system/lib64/libart.so (art::Barrier::~Barrier()+813)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #7 pc 000000000053de1a  /system/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+394)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #8 pc 00000000004ffea4  /system/lib64/libart.so (art::Runtime::Abort()+660)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #9 pc 0000000000178d71  /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #10 pc 00000000002f00fd  /system/lib64/libart.so (art::IndirectReferenceTable::Add(unsigned int, art::mirror::Object*)+1005)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #11 pc 00000000003ee19a  /system/lib64/libart.so (art::JNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+586)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #12 pc 00000000001abdf8  /system/lib64/libart.so (art::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, __va_list_tag*, art::Primitive::Type, art::InvokeType)+1736)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #13 pc 00000000001ae031  /system/lib64/libart.so (art::CheckJNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+33)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #14 pc 000000000004555d  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (_JNIEnv::CallObjectMethod(_jobject*, _jmethodID*, ...)+157)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #15 pc 000000000003beb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+69)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #16 pc 00000000001e8585  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #17 pc 00000000001e7020  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #18 pc 00000000001d8fb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #19 pc 00000000001d6961  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #20 pc 00000000000e5f19  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #21 pc 00000000002a96c6  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86)
    07-23 11:35:46.019  1640  1640 F DEBUG   :     #22 pc 00000000002b202e  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #23 pc 000000000026cb84  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #24 pc 000000000027615a  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #25 pc 00000000001e8618  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #26 pc 00000000001e7066  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #27 pc 00000000001d8fb5  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #28 pc 00000000001d6961  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #29 pc 00000000000e5f19  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #30 pc 00000000002a96c6  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #31 pc 00000000002c0713  /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #32 pc 0000000000084eee  /system/lib64/libc.so (__pthread_start(void*)+46)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #33 pc 00000000000296eb  /system/lib64/libc.so (__start_thread+11)
    07-23 11:35:46.020  1640  1640 F DEBUG   :     #34 pc 000000000001ce55  /system/lib64/libc.so (__bionic_clone+53)
    07-23 11:35:46.179  1640  1640 F DEBUG   :
    07-23 11:35:46.179  1640  1640 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_00

After some investigation, we think this was introduced in 35f41dc.

I could reproduce the issue in a simple test case:

    [Test]
    public void PutAndGetManyValues ()
    {
        for (int i = 0; i < Count; i++) {
            using var prefs = GetPreferences ();
            using var editor = prefs.Edit ();
            editor.PutString ("key" + i, "value" + i);
            editor.Apply ();
        }

        for (int i = 0; i < Count; i++) {
            using var prefs = GetPreferences ();
            Assert.AreEqual ("value" + i, prefs.GetString ("key" + i, null));
        }
    }

Which also crashed with:

    07-24 09:39:02.615  4623  4638 I NUnit   : SharedPreferencesTest
    07-24 09:39:02.615  4623  4638 I NUnit   : PutAndGetManyValues
    07-24 09:39:02.719  4623  4638 F art     : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)

I updated `TypeManager` to use a `try-finally` block, such as:

    JniObjectReference typeClass = default;
    JniObjectReference handleClass = default;
    try {
        //...
    } finally {
        JniObjectReference.Dispose (ref handleClass);
        JniObjectReference.Dispose (ref typeClass);
    }

And it appears the test case now passes on API 23 emulators. Hoping
this will also fix .NET MAUI.
jonpryor pushed a commit that referenced this issue Sep 23, 2024
…#9315)

Fixes: #9200

Context: 86260ed

If you use .NET resource files for localization, a'la:

 1. Create new .net MAUI project `dotnet new maui`
 2. Add `AppResources.resx`
 3. Add `AppResources.pt.resx`
 4. Add [Translation to a Page][0]
 5. Build the app in Release configuration: `dotnet build -c Release`
 6. Run the app from (5) 

If (5) is done *on macOS or Linux*, then (6) will run fine.

If (5) is done *on Windows*, then (6) will crash:

	W monodroid-assembly: Assembly 'pt-PT/Testnet9.resources' (hash 0x1cab5580a98905b0) not found
	W monodroid-assembly: open_from_bundles: failed to load bundled assembly pt-PT/Testnet9.resources
	W monodroid-assembly: Assembly 'pt-PT/Testnet9.resources' (hash 0x1cab5580a98905b0) not found
	W monodroid-assembly: open_from_bundles: failed to load bundled assembly pt-PT/Testnet9.resources
	F monodroid-assembly: Failed to look up image index for hash 0x7357acbda27bdba3
	F monodroid: Abort at /Users/runner/work/1/s/xamarin-android/src/native/monodroid/mono-image-loader.hh:120:5 ('static MonoImage *xamarin::android::internal::MonoImageLoader::stash_and_return(MonoImage *, MonoImageOpenStatus, hash_t)')
	F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 8622 (nyname.testnet9), pid 8622 (nyname.testnet9)
	…
	I crash_dump64: performing dump of process 8622 (target tid = 8622)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'google/raven/raven:14/AP2A.240805.005.F1/12043167:user/release-keys'
	F DEBUG   : Revision: 'MP1.0'
	F DEBUG   : ABI: 'arm64'
	F DEBUG   : Timestamp: 2024-09-19 14:56:09.282050201-0400
	F DEBUG   : Process uptime: 1s
	F DEBUG   : Cmdline: com.companyname.testnet9
	F DEBUG   : pid: 8622, tid: 8622, name: nyname.testnet9  >>> com.companyname.testnet9 <<<
	F DEBUG   : uid: 10432
	F DEBUG   : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
	F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
	F DEBUG   : Abort message: 'Failed to look up image index for hash 0x7357acbda27bdba3'
	F DEBUG   :     x0  0000000000000000  x1  00000000000021ae  x2  0000000000000006  x3  0000007fe644e310
	F DEBUG   :     x4  2e722e302e6a716e  x5  2e722e302e6a716e  x6  2e722e302e6a716e  x7  7f7f7f7f7f7f7f7f
	F DEBUG   :     x8  00000000000000f0  x9  0000007af562a350  x10 0000000000000001  x11 0000007af567b170
	F DEBUG   :     x12 0000007fe644cc20  x13 00000000000000de  x14 0000007fe644de48  x15 0000003e2efa613a
	F DEBUG   :     x16 0000007af56e1fd0  x17 0000007af56cd560  x18 0000007b1573c000  x19 00000000000021ae
	F DEBUG   :     x20 00000000000021ae  x21 00000000ffffffff  x22 000000773e5ed5a8  x23 000000784cd6dc8c
	F DEBUG   :     x24 000000773e5ed5c0  x25 0000007b14e0aac0  x26 0000007fe644e428  x27 0000007b14e0aac0
	F DEBUG   :     x28 0000000000000001  x29 0000007fe644e390
	F DEBUG   :     lr  0000007af56648b8  sp  0000007fe644e2f0  pc  0000007af56648e4  pst 0000000000001000
	F DEBUG   : 8 total frames
	F DEBUG   : backtrace:
	F DEBUG   :       #00 pc 000000000005d8e4  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 1d36f8ae6e0af6158793abea7d4f4f2b)
	F DEBUG   :       #1 pc 00000000000450bc  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonodroid.so (xamarin::android::Helpers::abort_application(bool, std::__ndk1::source_location)+68) (BuildId: 2c6d565f407362f1538c0daa0faadd527d3f394d)
	F DEBUG   :       #2 pc 000000000001ffe4  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::open_from_bundles(void*, _MonoAssemblyName*, char**, void*, _MonoError*)+5672) (BuildId: 2c6d565f407362f1538c0daa0faadd527d3f394d)
	F DEBUG   :       #3 pc 0000000000209de0  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonosgen-2.0.so (BuildId: ed96d22c7f8696c1b93010ad15c389fcae5460db)
	F DEBUG   :       #4 pc 00000000002072cc  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonosgen-2.0.so (mono_assembly_request_byname+972) (BuildId: ed96d22c7f8696c1b93010ad15c389fcae5460db)
	F DEBUG   :       #5 pc 0000000000204de4  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonosgen-2.0.so (BuildId: ed96d22c7f8696c1b93010ad15c389fcae5460db)
	F DEBUG   :       #6 pc 0000000000236c8c  /data/app/~~UeL3IzhnnKWaWNC3QvJzLQ==/com.companyname.testnet9-JRe5kbYFfMvbdm6sggxl4Q==/lib/arm64/libmonosgen-2.0.so (BuildId: ed96d22c7f8696c1b93010ad15c389fcae5460db)
	F DEBUG   :       #7 pc 0000000000007ee4  <anonymous:7b0493d000>

In 86260ed (and earlier?), assemblies are not loaded "by name".
Instead, at build-time assembly names are *hashed*, and at runtime
the name of the assembly to load is also hashed, and we load the
assembly based on the assembly name hash; see e.g.
`AssemblyStoreIndexEntry::name_hash` from 86260ed.

Additionally, with resource assemblies we don't hash *just* the
assembly name, e.g. `Testnet9.resources.dll`, but also include the
"directory" containing the assembly, e.g. `pt/Testnet9.resources.dll`.

Of note is the directory separator character to use: the value hashed
at runtime is in `EmbeddedAssemblies::open_from_bundles()`:

	if (culture != nullptr && *culture != '\0') {
	    name.append_c (culture);
	    name.append (zip_path_separator);
	}
	name.append_c (asmname);

`zip_path_separator` is `/`, meaning that the compile-time hash
values *also* need to use `/` to be consistent.

The problem is that `/` *wasn't* consistently used to build the
compile-time hash values;
`MarshalMethodsNativeAssemblyGenerator.AddAssemblyImageCache()` used
`Path.Combine()`, which would use `\` on Windows, not `/`.

The result is that if the app was built on Windows, the compile-time
data would hash e.g. `pt\Testnet9.dll`, which would be a different
hash value than that produced by `pt/Testnet9.dll`.  This in turn
would result in a "lookup miss":

	F monodroid-assembly: Failed to look up image index for hash 0x7357acbda27bdba3

followed by an abort.

Fix this by updating `AddAssemblyImageCache()` to normalize on `/`.

[0]: https://learn.microsoft.com/dotnet/maui/fundamentals/localization?view=net-maui-8.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: App Runtime Issues in `libmonodroid.so`.
Projects
None yet
Development

No branches or pull requests

2 participants