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

[Xamarin.Android.NUnitLite] Import from monodroid/ae417a99 #13

Merged
merged 1 commit into from
May 10, 2016

Conversation

jonpryor
Copy link
Member

Xamarin.Android.NUnitLite is a copy of NunitLite, modified for use
with Xamarin.Android and to provide a Xamarin.Android GUI.

@jonpryor
Copy link
Member Author

DO NOT MERGE.

This PR builds from the command line, but Xamarin Studio 6 doesn't like it. Loading the solution results in an error dialog:

Error while trying to load the project '.../src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj': Project does not support framework 'MonoAndroid,Version=v6.0'

@radical: Any idea why Xamarin Studio shows the above error message, and how to fix it?

@jonpryor
Copy link
Member Author

jonpryor commented Apr 29, 2016

Xamarin Studio 6.0 will load the project without error if I modify the original 364d8ac3 commit to include this:

diff --git a/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj b/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
index 5b5ecdf..b22e7ef 100644
--- a/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
+++ b/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
@@ -7,10 +7,10 @@
     <OutputType>Library</OutputType>
     <RootNamespace>Xamarin.Android.NUnitLite</RootNamespace>
     <AssemblyName>Xamarin.Android.NUnitLite</AssemblyName>
+    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
   </PropertyGroup>
   <Import Project="..\..\Configuration.props" />
   <PropertyGroup>
-    <TargetFrameworkVersion>$(AndroidFrameworkVersion)</TargetFrameworkVersion>
     <AndroidSdkDirectory>$(AndroidToolchainDirectory)\sdk</AndroidSdkDirectory>
     <AndroidNdkDirectory>$(AndroidToolchainDirectory)\ndk</AndroidNdkDirectory>
   </PropertyGroup>
@@ -349,6 +349,7 @@
   <Import Project="$(OutputPath)\..\..\..\xbuild\Xamarin\Android\Xamarin.Android.CSharp.targets" />
   <PropertyGroup>
     <ImplicitlyExpandDesignTimeFacades>False</ImplicitlyExpandDesignTimeFacades>
+    <TargetFrameworkIdentifier></TargetFrameworkIdentifier>
   </PropertyGroup>
   <ItemGroup>
     <ProjectReference Include="..\Mono.Android\Mono.Android.csproj">

This PR has been updated to include the above patch.

The "problem" appears to be MonoDevelop.Projects/DotNetProject.cs, which requires that that the combination of $(TargetFrameworkIdentifier) and $(TargetFrameworkVersion) be a supported value, and the default Xamarin studio .NET Project add-in only supports "normal" .NET project versions.

The "fix" used above is to explicitly replace $(TargetFrameworkIdentifier) after importing Xamarin.Android.CSharp.targets, as Xamarin.Android.Common.targets explicitly sets $(TargetFrameworkIdentifier). This replacement allows Xamarin Studio to load the project...

...but I don't know what other ramifications this will imply.

@jonpryor
Copy link
Member Author

jonpryor commented May 4, 2016

The latest update reverts the previous change, and instead adds a $(ProjectTypeGuids) MSBuild property so that Xamarin Studio can "properly" load the project.

diff --git a/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj b/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
index b22e7ef..5f3fe9a 100644
--- a/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
+++ b/src/Xamarin.Android.NUnitLite/Xamarin.Android.NUnitLite.csproj
@@ -4,16 +4,15 @@
     <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
     <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
     <ProjectGuid>{4D603AA3-3BFD-43C8-8050-0CD6C2601126}</ProjectGuid>
+    <ProjectTypeGuids>{EFBA0AD7-5A72-4C68-AF49-83D382785DCF};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>^M
     <OutputType>Library</OutputType>
     <RootNamespace>Xamarin.Android.NUnitLite</RootNamespace>
+    <MonoAndroidAssetsPrefix>Assets</MonoAndroidAssetsPrefix>^M
+    <MonoAndroidResourcePrefix>Resources</MonoAndroidResourcePrefix>^M
     <AssemblyName>Xamarin.Android.NUnitLite</AssemblyName>
-    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
+    <AndroidResgenFile>Resources\Resource.designer.cs</AndroidResgenFile>^M
   </PropertyGroup>
   <Import Project="..\..\Configuration.props" />
-  <PropertyGroup>
-    <AndroidSdkDirectory>$(AndroidToolchainDirectory)\sdk</AndroidSdkDirectory>
-    <AndroidNdkDirectory>$(AndroidToolchainDirectory)\ndk</AndroidNdkDirectory>
-  </PropertyGroup>
   <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
     <DebugSymbols>true</DebugSymbols>
     <DebugType>full</DebugType>
@@ -349,7 +348,6 @@
   <Import Project="$(OutputPath)\..\..\..\xbuild\Xamarin\Android\Xamarin.Android.CSharp.targets" />
   <PropertyGroup>
     <ImplicitlyExpandDesignTimeFacades>False</ImplicitlyExpandDesignTimeFacades>
-    <TargetFrameworkIdentifier></TargetFrameworkIdentifier>
   </PropertyGroup>
   <ItemGroup>
     <ProjectReference Include="..\Mono.Android\Mono.Android.csproj">

Pro: Xamarin Studio is able to load the project without generating warnings, and the project can be built from both Xamarin Studio (OS X) and command-line.

Con: I have no idea at all what will happen on Linux, e.g. with MonoDevelop. Will $(ProjectTypeGuids) be ignored? Will it prevent the project from being loaded? I don't know.

@jonpryor
Copy link
Member Author

jonpryor commented May 4, 2016

...but I don't know what other ramifications this will imply.

Clearing $(TargetFrameworkIdentifier) can break things like the _GetReferenceAssemblyPaths target, so that's not a good solution.

@jonpryor
Copy link
Member Author

jonpryor commented May 4, 2016

Con: I have no idea at all what will happen on Linux

Fortunately, that's rephrase-able and testable: what happens if we set $(ProjectTypeGuids) to a new GUID, as produced by uuidgen?

Answer: Xamarin Studio really doesn't like that, and refuses to load the project:

Xamarin Studio Error

@jonpryor jonpryor force-pushed the jonp-nunit branch 2 times, most recently from 5c429ee to ac3534d Compare May 4, 2016 20:20
@jonpryor
Copy link
Member Author

jonpryor commented May 4, 2016

After some discussion, we're going to drop the "goal" of building within MonoDevelop on Linux. The MonoDevelop build system can be extended to support loading projects that omit the "flavor" GUID -- closer to what Visual Studio does -- but there is no timeframe for this support, and we kinda really need Xamarin.Android.NUniteLite so that we can start migrating over unit tests...

Goodbye, Linux IDE build support. I hardly knew ye. (Granted, nothing reliably builds on Linux anyway, but now the entire prospect just got a lot harder.)

/// <summary>
/// Count of the test cases ( 1 if this is a test case )
/// </summary>
int TestCaseCount { get; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jonpryor Indentation is off :(

@dellis1972
Copy link
Contributor

@jonpryor This looks ok for the most part. There are a bunch of indentation issues probably as a result of the original code being a mix of spaces/tabs.
I think we should fix them up. We should probably add a XS code formatting rule to the projects as well so that the IDE's will use the right formatting. We have one of those in MonoGame so I'll see if I can bring that over. I assume we are using VS code formatting.

@dellis1972
Copy link
Contributor

PR #22 adds the code formatting xml file

@jonpryor jonpryor force-pushed the jonp-nunit branch 4 times, most recently from 85442d3 to bc467e6 Compare May 9, 2016 19:20
Xamarin.Android.NUnitLite is a copy of NUnitLite, modified for use
with Xamarin.Android and to provide a Xamarin.Android test runner GUI.
@dellis1972 dellis1972 merged commit 8b0d145 into dotnet:master May 10, 2016
jonpryor added a commit that referenced this pull request Feb 16, 2018
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
baulig pushed a commit that referenced this pull request Feb 21, 2018
commit d3ad544
Author: Dean Ellis <dellis1972@googlemail.com>
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 <jonpryor@vt.edu>
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 <dellis1972@googlemail.com>
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 <atsushieno@gmail.com>
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 <luhenry@microsoft.com>
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 <jonpryor@vt.edu>
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 <msylvia@nukefile.net>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <dellis1972@googlemail.com>
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 <luhenry@microsoft.com>
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 <dellis1972@googlemail.com>
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 <jonpryor@vt.edu>
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 <jonpryor@vt.edu>
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 <pecolli@microsoft.com>
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 <dellis1972@googlemail.com>
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 <jonpryor@vt.edu>
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 <dellis1972@googlemail.com>
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 <jonpryor@vt.edu>
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 <jonathan.peppers@gmail.com>
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.
grendello added a commit to grendello/xamarin-android that referenced this pull request 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 added a commit to grendello/xamarin-android that referenced this pull request 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.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Jul 28, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Jul 28, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side-effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Jul 29, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Nov 8, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Nov 8, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Nov 12, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Add a new `AndroidAotModeHybridAbortsOnArmeabiV7a` on-device test to
remind the team to remove the error if hybrid AOT becomes compatible
with armeabi-v7a in the future.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
brendanzagaeski added a commit to brendanzagaeski/xamarin-android that referenced this pull request Nov 12, 2020
…abi-v7a

Context: dotnet#1218 (comment)

The undocumented, experimental `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a
crash.

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known issue
and reduce the time users might spend searching for the cause of the
crash.

Example of the current crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `BuildIncrementalAot` test so that it sets
`$(AndroidSupportedAbis)`.  A side effect is that the test cases that
use `$(AndroidAotMode)`=`Full` now build successfully.  Note that
although those test cases now build successfully, the resulting app
packages abort when run on device because Xamarin.Android requires JIT
compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
jonpryor pushed a commit that referenced this pull request Dec 9, 2020
…4966)

Context: #1218 (comment)

The undocumented, experimental, `Hybrid` value for the
`$(AndroidAotMode)` MSBuild property is not currently compatible with
the armeabi-v7a target ABI.  Attempting to run an app built with
`$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in
a crash:

	F libc    : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1)
	W         : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys'
	F DEBUG   : Revision: 'p3b0'
	F DEBUG   : ABI: 'arm'
	F DEBUG   : pid: 31140, tid: 31140, name: ppxamarinforms1  >>> com.companyname.mobileappxamarinforms1 <<<
	F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8
	F DEBUG   :     r0 be9384d4  r1 00000000  r2 be9385a0  r3 9320b1c0
	F DEBUG   :     r4 00000000  r5 94167208  r6 00000000  r7 be938584
	F DEBUG   :     r8 be938838  r9 ae040008  sl 00000000  fp be9385a0
	F DEBUG   :     ip 913a50c8  sp be9384e4  lr 942a8420  pc 913a50c8  cpsr 000f0010
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 000250c8  [anon:libc_malloc:91380000]
	F DEBUG   :     #1 pc 0000141c  <anonymous:942a7000>
	W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740}
	I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty #13
	D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10)
	D ActivityManager: cleanUpApplicationRecord -- 30471
	E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ]
	W         : debuggerd: resuming target 31140
	I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
	W ActivityManager:   Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity
	I Zygote  : Process 31140 exited due to signal (11)

Since it is known that this configuration currently produces a crash,
emit a build error for it to improve the visibility of the known
issue and reduce the time users might spend searching for the cause
of the crash.

Other changes:

Update the `HybridAOT` test to cover the new error.

Correct the `IncrementalBuildTest.BuildIncrementalAot()` test so that
it sets `$(AndroidSupportedAbis)`.  A side effect is that the test
cases that use `$(AndroidAotMode)`=`Full` now build successfully.
Note that although those test cases now build successfully, the
resulting app packages abort when run on device because Xamarin.Android
requires JIT compilation:

	Unhandled Exception:
	System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode.

TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by
updating error XA3002.
grendello added a commit to grendello/xamarin-android that referenced this pull request Nov 22, 2022
It won't fix the failure, but extra logging might be useful at some
point. The current failure is:

    droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of invalid jobject 0x7100941bb830
    backtrace:
           #00 pc 00000000000943f8  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+24) (BuildId: a08a19770d6696739c847e29c3f5f650)
           #1 pc 0000000000097146  /apex/com.android.runtime/lib64/bionic/libc.so (abort+182) (BuildId: a08a19770d6696739c847e29c3f5f650)
           #2 pc 000000000055321f  /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+2399) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           #3 pc 000000000000c873  /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+611) (BuildId: 40d2b536dbf0730fdc31abd2b469f94f)
           dotnet#4 pc 00000000003ede64  /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1604) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#5 pc 00000000003ee16a  /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+234) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#6 pc 00000000005adf7b  /apex/com.android.runtime/lib64/libart.so (art::Thread::DecodeJObject(_jobject*) const+875) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#7 pc 00000000003def7b  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckInstance(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck::InstanceKind, _jobject*, bool)+91) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#8 pc 00000000003de1e5  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+485) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#9 pc 00000000003de2d4  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+724) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#10 pc 00000000003dd712  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+690) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#11 pc 00000000003e28c0  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CheckCallArgs(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck&, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, art::InvokeType, art::(anonymous namespace)::VarArgs const*)+160) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#12 pc 00000000003e1a9e  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, __va_list_tag*, art::Primitive::Type, art::InvokeType)+910) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#13 pc 00000000003cf551  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CallObjectMethod(_JNIEnv*, _jobject*, _jmethodID*, ...)+177) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
           dotnet#14 pc 00000000000013ec  /data/app/Mono.Android.NET_Tests--O9vgexkYeCx3nX-AuvLTQ==/split_config.x86_64.apk!libreuse-threads.so (offset 0xa8d000) (BuildId: 562d86d81ebdd3bb6b7528e2a9235ff84827294e)
           dotnet#15 pc 0000000000100fce  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+30) (BuildId: a08a19770d6696739c847e29c3f5f650)
           dotnet#16 pc 0000000000098fe7  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+55) (BuildId: a08a19770d6696739c847e29c3f5f650)
jonpryor added a commit that referenced this pull request 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 added a commit that referenced this pull request Jan 27, 2024
Context: xamarin/monodroid@e3e4f123d8
Context: dotnet/java-interop@005c9141
Context: dotnet/java-interop#1181

We've been trying to track down a JNI error which occurs when trying
to use dotnet/java-interop@005c9141, resembling:

	I monodroid-lref: +l+ lrefc 1 handle 0x71/L from thread '(null)'(1)
	D monodroid-gref:    at Android.Runtime.AndroidObjectReferenceManager.CreatedLocalReference(JniObjectReference , Int32& )
	D monodroid-gref:    at Java.Interop.JniRuntime.JniObjectReferenceManager.CreatedLocalReference(JniEnvironmentInfo , JniObjectReference )
	D monodroid-gref:    at Java.Interop.JniEnvironment.LogCreateLocalRef(JniObjectReference )
	D monodroid-gref:    at Java.Interop.JniEnvironment.LogCreateLocalRef(IntPtr )
	D monodroid-gref:    at Java.Interop.JniEnvironment.InstanceMethods.CallObjectMethod(JniObjectReference , JniMethodInfo )
	D monodroid-gref:    at Android.Runtime.JNIEnv.CallObjectMethod(IntPtr , IntPtr )
	D monodroid-gref:    at Android.Runtime.JavaSet.Iterator()
	D monodroid-gref:    at Android.Runtime.JavaSet`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].GetEnumerator()
	D monodroid-gref:    at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].ProcessArguments()
	D monodroid-gref:    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)
	D monodroid-gref:    at Android.App.Instrumentation.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_arguments)
	D monodroid-gref:    at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPL_V(_JniMarshal_PPL_V callback, IntPtr jnienv, IntPtr klazz, IntPtr p0)
	…
	I monodroid-lref: -l- lrefc 0 handle 0x71/L from thread '(null)'(1)
	D monodroid-gref:    at Android.Runtime.AndroidObjectReferenceManager.DeleteLocalReference(JniObjectReference& , Int32& )
	D monodroid-gref:    at Java.Interop.JniRuntime.JniObjectReferenceManager.DeleteLocalReference(JniEnvironmentInfo , JniObjectReference& )
	D monodroid-gref:    at Java.Interop.JniObjectReference.Dispose(JniObjectReference& reference)
	D monodroid-gref:    at Android.Runtime.JNIEnv.DeleteLocalRef(IntPtr )
	D monodroid-gref:    at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
	D monodroid-gref:    at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	D monodroid-gref:    at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
	D monodroid-gref:    at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
	D monodroid-gref:    at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
	D monodroid-gref:    at Android.Runtime.JavaSet.Iterator()
	D monodroid-gref:    at Android.Runtime.JavaSet`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].GetEnumerator()
	D monodroid-gref:    at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].ProcessArguments()
	D monodroid-gref:    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)
	D monodroid-gref:    at Android.App.Instrumentation.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_arguments)
	D monodroid-gref:    at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPL_V(_JniMarshal_PPL_V callback, IntPtr jnienv, IntPtr klazz, IntPtr p0)
	D monodroid-gref:
	E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x71  (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 0x71
	…
	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)

This has been "fun".

The problem:

 1. dotnet/java-interop@005c9141 relies on/requires additional
    typemaps in order to "fix" some linker warnings.

    This felt "fine" at the time.

 2. However, the Java.Interop *unit tests* which test (1) involve
    "hand-written" typemap entries to allow things to work.

 3. In .NET Android, those hand-written typemap entries aren't used;
    instead, the normal .NET Android typemaps are used.

 4. .NET Android typemaps did not contain entries for the types
    introduced in (2), so various tests started failing.

 5. dotnet/java-interop#1181 attempts to fix this by extending
    Java Callable Wrappers and associated typemaps to support
    `Java.Interop.JavaObject` subclasses, which brings the new types
    in (2) into the "normal" typemap fold.

 6. However, some of those types "alias" `java.lang.Object`, and --
    for some "bizarre" random ordering reason -- a type within
    `Java.Interop-Tests.dll` becomes the preferred `System.Type`
    to return when looking up `java/lang/Object`.

 7. Which would *probably* be okay (if *really* weird), except that
    `GetJavaToManagedType()` returns null when the binding is within
    an assembly that hasn't been loaded yet.  As this codepath is
    getting hit during app startup, `Java.Interop-Tests` hasn't been
    loaded, so `GetJavaToManagedType()` returns null.

 8. Which means we're now in the scenario of being unable to find a
    binding/"wrapper class" for `java/lang/Object`, which we consider
    to be an error state.

Because it's an error state, we dutifully throw.

…except we've never actually hit this error state before --
HOW COULD WE?! -- which means we've found a bug in our error handling.

Quick, find the problem!

	JNIEnv.DeleteRef (handle, transfer);
	throw new NotSupportedException (
			FormattableString.Invariant ($"Internal error finding wrapper class for '{JNIEnv.GetClassNameFromInstance (handle)}'. (Where is the Java.Lang.Object wrapper?!)"),
			CreateJavaLocationException ());

The problem is a "use after free" bug:
`JNIEnv.DeleteRef(handle, transfer)` *invalidates `handle`*, and then
*immediately* afterward we call
`JNIEnv.GetClassNameFromInstance(handle)`, on the now invalid value.

BOOM goes the Android runtime.

(The `DeleteRef()` call was introduced in xamarin/monodroid@e3e4f123d8,
on 2011-Oct-19.  Over 12 years to encounter this scenario!)

Unfortunately, *just* fixing the "use-after-free" bug is insufficient;
if we throw that `NotSupportedException`, things *will* break
elsewhere.  We'll just have an "elegant unhandled exception" app crash
instead of a "THE WORLD IS ENDING" failed assertion crash.

We could go with the simple fix for the crash, but this means that in
order to integrate dotnet/java-interop@005c9141 &
dotnet/java-interop#1181 we'd have to figure out how to *ensure* that
`java/lang/Object` is bound as `Java.Lang.Object, Mono.Android`, not
`Java.InteropTests.JavaLangRemappingTestObject, Java.Interop-Tests`.

There may be a *slightly* more complicated fix which fixes both issues:
consider the `-l-` callstack:

	at Android.Runtime.JNIEnv.DeleteRef(IntPtr , JniHandleOwnership )
	at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
	at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
	at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
	at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
	at Android.Runtime.JavaSet.Iterator()

This is part of a generic `Object.GetObject<IIterator>()` invocation!
Additionally, because `IIterator` is an interface, in *normal* use
the `type` variable within `TypeManager.CreateInstance()` would be
`Java.Lang.Object, Mono.Android` and then ~immediately "discarded"
because `Java.Lang.Object` cannot be assigned to `IIterator`.

If we move the type compatibility check to *before* the
`type == null` check, we *may* also fix the
"`java/lang/Object` is bound as some unloadable type" issue.

Let's try that!
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants