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

"clang" is not always available. It needs to be customizible. #3

Closed
wants to merge 1 commit into from
Closed

"clang" is not always available. It needs to be customizible. #3

wants to merge 1 commit into from

Conversation

atsushieno
Copy link
Contributor

For example it is clang-3.5 etc. on Ubuntu.

For example it is clang-3.5 etc. on Ubuntu.
@jonpryor
Copy link
Member

i’d prefer a different approach. :-)

Instead, we should:

  1. Add $(HostCc) and $(HostCxx) MSBuild properties to Configuration.props and Configuration.Override.props.in
  2. Alter build-tools/mono-runtimes/mono-runtimes.projitems to use $(HostCc) and $(HostCxx) instead of hardcoding clang and clang++.

Once that is complete, you can copy Configuration.Override.props.in to Configuration.Override.props, alter $(HostCc) and $(HostCxx) as appropriate, and mono-runtimes.projitems will use your overriding values.

@atsushieno
Copy link
Contributor Author

That approach is good too but you need 99% identical changes to mine anyways.

@jonpryor
Copy link
Member

This PR is obsoleted by commit 0d7bc89 and the implementing of the above comment.

@jonpryor jonpryor closed this Apr 22, 2016
@atsushieno
Copy link
Contributor Author

yay!

radical pushed a commit that referenced this pull request May 8, 2018
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=25443
Fixes: dotnet/java-interop#2
Fixes: dotnet/java-interop#3

The problem with JniRuntime.JniValueManager.GetObject() is that it was
constrained to only return IJavaPeerable instances.  This constraint
in turn necessitated the introduction of JniMarshal.GetValue<T>()
(commit 1e14a61) so that "anything" could be stored within a
JavaObjectArray<T>, proxying values if required.  This in turn led to
a dichotomy: should JniRuntime.GetObject<T>() be used, or should
JniMarshal.GetValue<T>() be used?

This dichotomy was partially resolved in commit 77a6bf8, which
removed JniMarshal.GetValue<T>() and added a
JniRuntime.JniValueManager.GetValue<T>() method, but that just
introduced a different dichotomy: should JniValueManager.GetObject()
be used or JniValueManager.GetValue()?

Simplify this mess: kill JniValueManager.GetObject() (and all
overloads), and instead rely on JniValueManager.GetValue().

Additionally, add JniValueManager.CreateValue() overloads (Issue #3)
and fix JniValueMarshaler<T>.CreateGenericValue() logic to *not*
lookup registered values, as per commit 77a6bf8:

> clean[] up JniValueMarshaler.Create*Value() methods to always
> create values when able, simplifying the logic of
> JniValueMarshaler implementations.

Cleaning up these semantics is necessary so that
JniValueManager.CreateValue() can be meaningful.  The only time that
JniValueManager.CreateValue() won't create a *new* value is if the
value is a proxy'd instance, at which point we're not going to muck
with it and any resulting bugs are Not Our Problem™.

The primary change of killing JniValueManager.GetObject() required a
few secondary changes:

  * JniValueManager.RegisterObject<T>() can no longer throw a
    NotSupportedException when attempting to create an alias, as
    (1) the NotSupportedException is a semantic change from
    Xamarin.Android that we can't accept -- aliases are a fact of
    life, and will be required for .JavaCast<T> (Issue #10) -- and
    (2) the check was breaking unit tests.
    We now generate a warning to the GREF log when aliases are
    created, similar in spirit to what Xamarin.Android does.

  * ProxyValueMarshaler.CreateGenericValue() now falls back to
    JniValueManager.CreateObjectWrapper() instead of returning `null`.
    This was needed so that ValueManager.GetValue<Exception>(...)
    would work.

  * For a "unified type system"-like experience,
    JniValueManager.CreateObjectWrapper() now maps certain types to
    corresponding types, e.g. object is mapped to JavaObject, and
    Exception is mapped to JavaException.  This is likewise to support
    ValueManager.GetValue<Exception>(...) around a Java instance.
radical pushed a commit that referenced this pull request May 8, 2018
When `JniRuntime.CreationOptions.DestroyRuntimeOnDispose` is true,
`JavaVM::DestroyJavaVM()` will be invoked when the `JniRuntime`
instance is disposed *or* finalized.

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

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

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

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

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

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

Finalization:

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

JVM destruction:

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

AppDomain unload:

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

This randomly results in deadlock, and hung Jenkins bots.

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

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

This prevents the JVM from being destroyed, which in turn prevents the
hang during process shutdown.
grendello referenced this pull request in grendello/xamarin-android Jul 18, 2018
Xamarin.Android uses the ILRepack
task (https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task/) to repack/merge
the `Xamarin.Android.Build.Tasks` assembly, a step that is performed after the
`Xamarin.Android.Build.Tasks` project build completes. The step takes the
project's output assembly and several other dependencies and merges them into
one, replacing the original output assembly. For the majority of time it works
flawlessly, however the scenario described below causes a Mono runtime
crash (similar to this one mono/mono#9613, although
not identical).

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

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

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

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

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

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

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

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

The accompanying managed stacktrace looks as follows:

  Stacktrace:

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

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

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

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

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

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

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

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

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

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

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

This also improves rebuild times.

[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
jonpryor pushed a commit that referenced this pull request Aug 3, 2018
Xamarin.Android uses the [ILRepack task][0] to repack/merge the
`Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is
performed after the `Xamarin.Android.Build.Tasks.csproj` project's
`Build` target completes.  The step takes the project's output
assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other
dependencies, then merges them into one, *replacing* the original
output assembly.

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

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

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

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

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

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

This also improves rebuild times.

[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
lewurm added a commit to lewurm/xamarin-android that referenced this pull request Nov 20, 2018
dellis1972 referenced this pull request in dellis1972/xamarin-android Feb 5, 2019
When using fastdev typemaps we get the following error

```
01-31 10:57:34.336  5802  5802 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5802 (haredandroidios), pid 5802 (haredandroidios)
01-31 10:57:34.358  5829  5829 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
01-31 10:57:34.358  1685  1685 I /system/bin/tombstoned: received crash request for pid 5802
01-31 10:57:34.359  5829  5829 I crash_dump32: performing dump of process 5802 (target tid = 5802)
01-31 10:57:34.363  5829  5829 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-31 10:57:34.363  5829  5829 F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/test-keys'
01-31 10:57:34.363  5829  5829 F DEBUG   : Revision: '0'
01-31 10:57:34.363  5829  5829 F DEBUG   : ABI: 'x86'
01-31 10:57:34.363  5829  5829 F DEBUG   : pid: 5802, tid: 5802, name: haredandroidios  >>> com.xamarin.blankformssharedandroidios <<<
01-31 10:57:34.363  5829  5829 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
01-31 10:57:34.363  5829  5829 F DEBUG   : Cause: null pointer dereference
01-31 10:57:34.363  5829  5829 F DEBUG   :     eax 00000000  ebx e6b2e754  ecx 00000000  edx 00000000
01-31 10:57:34.363  5829  5829 F DEBUG   :     edi e0cc58f0  esi 00000000
01-31 10:57:34.363  5829  5829 F DEBUG   :     ebp ffd85ff8  esp ffd85fcc  eip e6a60532
01-31 10:57:34.459  5829  5829 F DEBUG   :
01-31 10:57:34.459  5829  5829 F DEBUG   : backtrace:
01-31 10:57:34.459  5829  5829 F DEBUG   :     #00 pc 0001e532  /system/lib/libc.so (strlen+18)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #1 pc 00075952  /system/lib/libc.so (strdup+34)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #2 pc 0000f6ab  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::add_type_mapping(xamarin::android::internal::TypeMappingInfo**, char const*, char const*, char const*)+667)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #3 pc 00010ed7  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::try_load_typemaps_from_directory(char const*)+871)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #4 pc 000233b8  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (gather_bundled_assemblies(_JNIEnv*, xamarin::android::jstring_array_wrapper&, bool, int*)+248)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #5 pc 000229c6  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jstring*, _jobject*, bool)+166)
01-31 10:57:34.459  5829  5829 F DEBUG   :     #6 pc 0001f20c  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_and_initialize_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jobjectArray*, _jobject*, bool)+204)
01-31 10:57:34.460  5829  5829 F DEBUG   :     #7 pc 0001c7af  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_init+4255)
```

The was down to the `try_load_typemaps_from_directory` passing a
`nullptr` to the `add_type_mapping` method. This method was
calling `strdup`, which does NOT like `nullptr`.

Since the `source_entry` argument is only used for logging we
migth as well create a constant string with a value of
`.__override__` so that if there is a problem we can see
from the logs this was a fastdev issue.
jonpryor pushed a commit that referenced this pull request Feb 5, 2019
When using fastdev typemaps files we get the following error:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5802 (haredandroidios), pid 5802 (haredandroidios)
	I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	I /system/bin/tombstoned: received crash request for pid 5802
	I crash_dump32: performing dump of process 5802 (target tid = 5802)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/test-keys'
	F DEBUG   : Revision: '0'
	F DEBUG   : ABI: 'x86'
	F DEBUG   : pid: 5802, tid: 5802, name: haredandroidios  >>> com.xamarin.blankformssharedandroidios <<<
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
	F DEBUG   : Cause: null pointer dereference
	F DEBUG   :     eax 00000000  ebx e6b2e754  ecx 00000000  edx 00000000
	F DEBUG   :     edi e0cc58f0  esi 00000000
	F DEBUG   :     ebp ffd85ff8  esp ffd85fcc  eip e6a60532
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 0001e532  /system/lib/libc.so (strlen+18)
	F DEBUG   :     #1 pc 00075952  /system/lib/libc.so (strdup+34)
	F DEBUG   :     #2 pc 0000f6ab  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::add_type_mapping(xamarin::android::internal::TypeMappingInfo**, char const*, char const*, char const*)+667)
	F DEBUG   :     #3 pc 00010ed7  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::try_load_typemaps_from_directory(char const*)+871)
	F DEBUG   :     #4 pc 000233b8  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (gather_bundled_assemblies(_JNIEnv*, xamarin::android::jstring_array_wrapper&, bool, int*)+248)
	F DEBUG   :     #5 pc 000229c6  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jstring*, _jobject*, bool)+166)
	F DEBUG   :     #6 pc 0001f20c  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_and_initialize_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jobjectArray*, _jobject*, bool)+204)
	F DEBUG   :     #7 pc 0001c7af  /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_init+4255)


The was down to the `try_load_typemaps_from_directory()` passing a
`nullptr` to the `add_type_mapping()` method.  This method was
calling **strdup**(3), which does NOT like `nullptr`.

Since the `source_entry` argument is only used for logging we might
as well create a constant string with a value of `.__override__` so
that if there is a problem we can see from the logs this was a
fastdev issue.
dellis1972 referenced this pull request in dellis1972/xamarin-android Feb 13, 2019
# This is the 1st commit message:
Initial Stable Id stuff

# The commit message #2 will be skipped:

#	rework code a bit

# The commit message #3 will be skipped:

#	FileWrites
dellis1972 referenced this pull request in dellis1972/xamarin-android Apr 29, 2019
# This is the 1st commit message:
Initial Stable Id stuff

# The commit message #2 will be skipped:

#	rework code a bit

# The commit message #3 will be skipped:

#	FileWrites
grendello referenced this pull request in grendello/xamarin-android May 26, 2020
Fixes: dotnet#4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9

Whenever Xamarin.Android runtime needs to instantiate a managed type, it
first looks it up by calling the following function:

    MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);

The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `null`, it should cause Mono to find the correct image
containing the type and load it, if not already loaded.

The pointer is propagated down the call chain inside Mono and due to one
of the functions called not properly validating its arguments, the
`null` pointer was dereferenced, leading to a crash similar to:

    libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3)
    crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    /system/bin/tombstoned: received crash request for pid 11029
    crash_dump64: performing dump of process 11029 (target tid = 11029)
    DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys'
    DEBUG   : Revision: '0'
    DEBUG   : ABI: 'x86_64'
    DEBUG   : Timestamp: 2020-05-25 14:45:29+0200
    DEBUG   : pid: 11029, tid: 11029, name: ompanyname.app3  >>> com.companyname.app3 <<<
    DEBUG   : uid: 10134
    DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0
    DEBUG   : Cause: null pointer dereference
    DEBUG   :     rax 000000000000002f  rbx 0000000000000001  rcx 0000000000000000  rdx 0000000000000030
    DEBUG   :     r8  0000000000000003  r9  000000000013e2e2  r10 0173eed800000000  r11 0000000000000206
    DEBUG   :     r12 0000000000000000  r13 00007478530343c0  r14 00007478075eda33  r15 000074780763efb0
    DEBUG   :     rdi 0000000000000000  rsi 00007478e2cb14d0
    DEBUG   :     rbp 00007ffef3a35680  rsp 00007ffef3a355d0  rip 0000747807a4066a
    DEBUG   :
    DEBUG   : backtrace:
    DEBUG   :       #00 pc 00000000003ba66a  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474)
    DEBUG   :       #1 pc 00000000003ba3d1  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321)
    DEBUG   :       #2 pc 00000000003ba26d  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125)
    DEBUG   :       #3 pc 000000000000ddb5  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       dotnet#4 pc 000000000000def3  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       dotnet#5 pc 0000000000069532  <anonymous:5ad25000>

Mono commit mono/mono@10795da1c06 fixes this issue.

Other changes:

 * mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
 * mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159
 * mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
grendello referenced this pull request in grendello/xamarin-android May 27, 2020
Fixes: dotnet#4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9

Whenever Xamarin.Android runtime needs to instantiate a managed type, it
first looks it up by calling the following function:

    MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);

The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `null`, it should cause Mono to find the correct image
containing the type and load it, if not already loaded.

The pointer is propagated down the call chain inside Mono and due to one
of the functions called not properly validating its arguments, the
`null` pointer was dereferenced, leading to a crash similar to:

    libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3)
    crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    /system/bin/tombstoned: received crash request for pid 11029
    crash_dump64: performing dump of process 11029 (target tid = 11029)
    DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys'
    DEBUG   : Revision: '0'
    DEBUG   : ABI: 'x86_64'
    DEBUG   : Timestamp: 2020-05-25 14:45:29+0200
    DEBUG   : pid: 11029, tid: 11029, name: ompanyname.app3  >>> com.companyname.app3 <<<
    DEBUG   : uid: 10134
    DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0
    DEBUG   : Cause: null pointer dereference
    DEBUG   :     rax 000000000000002f  rbx 0000000000000001  rcx 0000000000000000  rdx 0000000000000030
    DEBUG   :     r8  0000000000000003  r9  000000000013e2e2  r10 0173eed800000000  r11 0000000000000206
    DEBUG   :     r12 0000000000000000  r13 00007478530343c0  r14 00007478075eda33  r15 000074780763efb0
    DEBUG   :     rdi 0000000000000000  rsi 00007478e2cb14d0
    DEBUG   :     rbp 00007ffef3a35680  rsp 00007ffef3a355d0  rip 0000747807a4066a
    DEBUG   :
    DEBUG   : backtrace:
    DEBUG   :       #00 pc 00000000003ba66a  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474)
    DEBUG   :       #1 pc 00000000003ba3d1  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321)
    DEBUG   :       #2 pc 00000000003ba26d  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125)
    DEBUG   :       #3 pc 000000000000ddb5  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       dotnet#4 pc 000000000000def3  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       dotnet#5 pc 0000000000069532  <anonymous:5ad25000>

Mono commit mono/mono@10795da1c06 fixes this issue.

Other changes:

 * mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
 * mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159
 * mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
jonpryor pushed a commit that referenced this pull request May 27, 2020
Fixes: #4713

Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9

Changes: mono/mono@075c3f0...8c085a9

  * mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842)
  * mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
  * mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159
  * mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661)

Whenever Xamarin.Android runtime needs to instantiate a managed type,
it first looks it up by calling:

	MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);

The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `nullptr`, it should cause Mono to find the correct
image containing the type and load it, if not already loaded.

The pointer is propagated down the call chain inside Mono and due to
one of the functions called not properly validating its arguments, the
`nullptr` pointer was dereferenced, leading to a crash similar to:

	libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3)
	crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	/system/bin/tombstoned: received crash request for pid 11029
	crash_dump64: performing dump of process 11029 (target tid = 11029)
	DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys'
	DEBUG   : Revision: '0'
	DEBUG   : ABI: 'x86_64'
	DEBUG   : Timestamp: 2020-05-25 14:45:29+0200
	DEBUG   : pid: 11029, tid: 11029, name: ompanyname.app3  >>> com.companyname.app3 <<<
	DEBUG   : uid: 10134
	DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0
	DEBUG   : Cause: null pointer dereference
	DEBUG   :     rax 000000000000002f  rbx 0000000000000001  rcx 0000000000000000  rdx 0000000000000030
	DEBUG   :     r8  0000000000000003  r9  000000000013e2e2  r10 0173eed800000000  r11 0000000000000206
	DEBUG   :     r12 0000000000000000  r13 00007478530343c0  r14 00007478075eda33  r15 000074780763efb0
	DEBUG   :     rdi 0000000000000000  rsi 00007478e2cb14d0
	DEBUG   :     rbp 00007ffef3a35680  rsp 00007ffef3a355d0  rip 0000747807a4066a
	DEBUG   :
	DEBUG   : backtrace:
	DEBUG   :       #00 pc 00000000003ba66a  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474)
	DEBUG   :       #1 pc 00000000003ba3d1  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321)
	DEBUG   :       #2 pc 00000000003ba26d  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125)
	DEBUG   :       #3 pc 000000000000ddb5  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
	DEBUG   :       #4 pc 000000000000def3  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
	DEBUG   :       #5 pc 0000000000069532  <anonymous:5ad25000>

Mono commit mono/mono@10795da1c06 fixes this issue.
jonpryor pushed a commit that referenced this pull request May 28, 2020
Fixes: #4713

Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9

Changes: mono/mono@075c3f0...8c085a9

  * mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842)
  * mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
  * mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159
  * mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661)

Whenever Xamarin.Android runtime needs to instantiate a managed type,
it first looks it up by calling:

	MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);

The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `nullptr`, it should cause Mono to find the correct
image containing the type and load it, if not already loaded.

The pointer is propagated down the call chain inside Mono and due to
one of the functions called not properly validating its arguments, the
`nullptr` pointer was dereferenced, leading to a crash similar to:

	libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3)
	crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	/system/bin/tombstoned: received crash request for pid 11029
	crash_dump64: performing dump of process 11029 (target tid = 11029)
	DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys'
	DEBUG   : Revision: '0'
	DEBUG   : ABI: 'x86_64'
	DEBUG   : Timestamp: 2020-05-25 14:45:29+0200
	DEBUG   : pid: 11029, tid: 11029, name: ompanyname.app3  >>> com.companyname.app3 <<<
	DEBUG   : uid: 10134
	DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0
	DEBUG   : Cause: null pointer dereference
	DEBUG   :     rax 000000000000002f  rbx 0000000000000001  rcx 0000000000000000  rdx 0000000000000030
	DEBUG   :     r8  0000000000000003  r9  000000000013e2e2  r10 0173eed800000000  r11 0000000000000206
	DEBUG   :     r12 0000000000000000  r13 00007478530343c0  r14 00007478075eda33  r15 000074780763efb0
	DEBUG   :     rdi 0000000000000000  rsi 00007478e2cb14d0
	DEBUG   :     rbp 00007ffef3a35680  rsp 00007ffef3a355d0  rip 0000747807a4066a
	DEBUG   :
	DEBUG   : backtrace:
	DEBUG   :       #00 pc 00000000003ba66a  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474)
	DEBUG   :       #1 pc 00000000003ba3d1  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321)
	DEBUG   :       #2 pc 00000000003ba26d  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125)
	DEBUG   :       #3 pc 000000000000ddb5  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
	DEBUG   :       #4 pc 000000000000def3  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
	DEBUG   :       #5 pc 0000000000069532  <anonymous:5ad25000>

Mono commit mono/mono@10795da1c06 fixes this issue.
@moljac moljac mentioned this pull request Dec 2, 2020
grendello referenced this pull request in grendello/xamarin-android Feb 12, 2021
Context: dotnet#5619

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

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

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

  1. The Java	[`Class.getName`](https://developer.android.com/reference/java/lang/Class?hl=en#getName())
     method is absent
  2. `Class.getName` returns `nullptr` (a nameless class?)
  3. `env->GetStringUTFChars` returns `nullptr` (a memory allocation
     failure?)

Out of these, 3. appears to be most probable and this commit adds a
check for a `nullptr` pointer there, failing gracefully instead of
segfaulting.  This is NOT a fix for the original problem as we don't
know by what it is caused but, nevertheless, the `nullptr` check should
be there.
grendello referenced this pull request in grendello/xamarin-android Feb 16, 2021
Context: dotnet#5619

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

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

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

  1. The Java	[`Class.getName`](https://developer.android.com/reference/java/lang/Class?hl=en#getName())
     method is absent
  2. `Class.getName` returns `nullptr` (a nameless class?)
  3. `env->GetStringUTFChars` returns `nullptr` (a memory allocation
     failure?)

Out of these, 3. appears to be most probable and this commit adds a
check for a `nullptr` pointer there, failing gracefully instead of
segfaulting.  This is NOT a fix for the original problem as we don't
know by what it is caused but, nevertheless, the `nullptr` check should
be there.
jonpryor pushed a commit that referenced this pull request Feb 18, 2021
…5623)

Context: #5619

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

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

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

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

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

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

[0]: https://developer.android.com/reference/java/lang/Class?hl=en#getName()
[1]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetStringUTFChars
grendello referenced this pull request in grendello/xamarin-android Oct 26, 2021
Context: dotnet#6420 (comment)

Clang's AddressSanitizer detected the following:

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

Address of the offending region points to
`BasicUtilities::monodroid_strsplit` and is likely the line modified in
this commit.  Append terminating `nullptr` to vector instead of
overwriting the last element.
jonpryor pushed a commit that referenced this pull request Oct 29, 2021
Context: #6420 (comment)

Clang's AddressSanitizer detected the following:

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

Address of the offending region points to
`BasicUtilities::monodroid_strsplit()` and is likely the line
modified in this commit.  Append terminating `nullptr` to `vector`
instead of overwriting the last element.
jonathanpeppers referenced this pull request in jonathanpeppers/xamarin-android Dec 21, 2021
By default, this repo is checking out into:

    Finishing: Checkout xamarin/xamarin-android-private@main to s/xamarin-android-private

Which causes the build to fail on a later step:

    Could not find a part of the path '/Users/builder/azdo/_work/7/s/xamarin-android/build-tools/provisioning/xcode.csx'

Specify the path when checking out `self` to solve this issue.

Co-authored-by: Peter Collins <pecolli@microsoft.com>
jonpryor pushed a commit that referenced this pull request Jan 19, 2022
Commit 6eb11f1 added support for API-32, while keeping the .NET 6
default `$(TargetFramework)` value as `net6.0-android31.0`:

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

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

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

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

To fix this:

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

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

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

Now our `android` workload is:

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

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

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

And this assembly at runtime:

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

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

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

	dotnet build -t:Run -c Release

it crashes at runtime:

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

The crash can be avoided by disabling the linker:

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

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

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

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

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

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

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

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

So far, so reasonable, but…

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

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

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

All of this makes for a miserable debugging experience.

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

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

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

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

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

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

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

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

	dotnet build -t:Run -c Release

it crashes at runtime:

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

The crash can be avoided by disabling the linker:

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

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

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

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

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

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

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

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

So far, so reasonable, but…

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

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

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

All of this makes for a miserable debugging experience.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0]: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
simonrozsival referenced this pull request in simonrozsival/xamarin-android May 31, 2022
Context: dotnet/install-scripts#15
Context: https://dot.net/v1/dotnet-install.sh
Context: https://dot.net/v1/dotnet-install.ps1

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

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

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

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

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

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

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

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

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

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

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

[0]: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
jonpryor added a commit that referenced this pull request Jul 21, 2022
Changes: xamarin/NRefactory@495405a...f324292

  * xamarin/NRefactory@f3242923: Add .NET 6.0 target framework
  * xamarin/NRefactory@074fabe9: Merge pull request #3 from xamarin/net6
  * xamarin/NRefactory@fb5f1535: Merge pull request #4 from xamarin/dev/sandy/obsolete
  * xamarin/NRefactory@9233d6a8: Merge pull request #5 from xamarin/dev/sandy/mergemain
  * xamarin/NRefactory@b2991f92: Merge remote-tracking branch 'origin/master' into dev/sandy/mergemain
  * xamarin/NRefactory@e9c0609e: Fix use of obsolete member
  * xamarin/NRefactory@a6885a74: Allow building with .NET 6
jonpryor pushed a commit that referenced this pull request Jan 26, 2023
…7732)

Fixes: #7335

Context: d236af5

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

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

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

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

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

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

Fixes: dotnet#7335

Context: d236af5

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

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

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

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

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

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

Fixes: dotnet#7335

Context: d236af5

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

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

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

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

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

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

Fixes: dotnet#7335

Context: d236af5

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

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

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

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

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

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

Fixes: #7335

Context: d236af5

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

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

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

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

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

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

Fixes: #7335

Context: d236af5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0]: https://learn.microsoft.com/dotnet/api/system.reflection.module.moduleversionid?view=net-7.0
jonpryor added a commit that referenced this 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.
@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