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

[xaprepare] Update ExternalGitDependency usage #2

Merged
merged 1 commit into from
Jun 6, 2019

Conversation

pjcollins
Copy link

Allows a non-authorized https-based clone for local use cases, and cleans
up various logging events to ensure we don't leak secrets. Also includes
some minor azure-pipelines.yaml cleanup.

Allows a non-authorized https-based clone for local use cases, and cleans
up various logging events to ensure we don't leak secrets. Also includes
some minor azure-pipelines.yaml cleanup.
@pjcollins pjcollins requested a review from grendello as a code owner June 6, 2019 17:58
@grendello grendello merged commit 1aa491e into grendello:xa/bootstrap Jun 6, 2019
@pjcollins pjcollins deleted the externalgit-and-format branch June 6, 2019 18:10
grendello pushed a commit that referenced this pull request Jun 6, 2019
Allows a non-authorized https-based clone for local use cases, and cleans
up various logging events to ensure we don't leak secrets. Also includes
some minor azure-pipelines.yaml cleanup.
grendello pushed a commit that referenced this pull request Jun 6, 2019
Allows a non-authorized https-based clone for local use cases, and cleans
up various logging events to ensure we don't leak secrets. Also includes
some minor azure-pipelines.yaml cleanup.
grendello pushed a commit that referenced this pull request Jun 7, 2019
Allows a non-authorized https-based clone for local use cases, and cleans
up various logging events to ensure we don't leak secrets. Also includes
some minor azure-pipelines.yaml cleanup.
grendello pushed a commit that referenced this pull request Feb 12, 2020
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   :     dotnet#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   :     dotnet#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   :     dotnet#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   :     dotnet#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.
grendello added a commit that referenced this pull request Apr 8, 2020
Context: 7117414

7117414 introduced native code which queries
the Mono runtime to obtain an instance of `MonoClass` for a given
`MonoReflectionType` as well as the `MonoImage` associated with the
class.  However, it appears that in certain cases the class pointer
stored `MonoReflectionType` doesn't lead us to getting a valid
`MonoImage` instance, causing a segfault similar to:

    04-08 15:52:55.015 19030 19030 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021 in tid 19030 (s.swipeviewdemo), pid 19030 (s.swipeviewdemo)
    04-08 15:52:55.037 19061 19061 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    04-08 15:52:55.037  1834  1834 I /system/bin/tombstoned: received crash request for pid 19030
    04-08 15:52:55.038 19061 19061 I crash_dump32: performing dump of process 19030 (target tid = 19030)
    04-08 15:52:55.042 19061 19061 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    04-08 15:52:55.042 19061 19061 F DEBUG   : Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.191030.002/5978551:userdebug/dev-keys'
    04-08 15:52:55.043 19061 19061 F DEBUG   : Revision: '0'
    04-08 15:52:55.043 19061 19061 F DEBUG   : ABI: 'x86'
    04-08 15:52:55.043 19061 19061 F DEBUG   : Timestamp: 2020-04-08 15:52:55+0200
    04-08 15:52:55.043 19061 19061 F DEBUG   : pid: 19030, tid: 19030, name: s.swipeviewdemo  >>> nl.versluis.swipeviewdemo <<<
    04-08 15:52:55.043 19061 19061 F DEBUG   : uid: 10135
    04-08 15:52:55.043 19061 19061 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021
    04-08 15:52:55.043 19061 19061 F DEBUG   :     eax 03000005  ebx cb9f4d24  ecx 7191c13b  edx 00000004
    04-08 15:52:55.043 19061 19061 F DEBUG   :     edi 03000005  esi ffb22080
    04-08 15:52:55.043 19061 19061 F DEBUG   :     ebp ffb22108  esp ffb2206c  eip cbcfc1e4
    04-08 15:52:55.077 19061 19061 F DEBUG   :
    04-08 15:52:55.077 19061 19061 F DEBUG   : backtrace:
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #00 pc 001b41e4  /data/app/Mono.Android.DebugRuntime-umHhDz421s4-tshrHwha0w==/lib/x86/libmonosgen-32bit-2.0.so (mono_image_get_name+4)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #1 pc 0000cac7  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoType*, _MonoClass*, unsigned char const*)+263) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #2 pc 0000c8cc  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+124) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #3 pc 0001621a  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+42) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       dotnet#4 pc 000325af  <anonymous:c7858000>

Investigating the issue I discovered that one of two things happened:

  1. the returned `MonoImage` instance was invalid, or
	2. the instance was valid but image name stored in `MonoImage` was
     `null`

In case of 1. I would see something similar to this in the crash log:

    04-08 15:52:55.015 19030 19030 I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
    04-08 15:52:55.015 19030 19030 I monodroid:   type == 0xc6e60d3c, klass == 0xc6e60cb8, mvid == 0xc8c02d90
    04-08 15:52:55.015 19030 19030 I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
    04-08 15:52:55.015 19030 19030 I monodroid:   calling mono_class_get_image (0xc6e60cb8)
    04-08 15:52:55.015 19030 19030 I monodroid:     image == 0x3000005

It would happen in 32-bit builds only, the 64-bit builds would lead to a
different issue, the 2. above:

    04-08 16:05:13.446 28985 28985 I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
    04-08 16:05:13.447 28985 28985 I monodroid:   type == 0x7ce3fecc78, klass == 0x7ce3fecb98, mvid == 0x7ce9404520
    04-08 16:05:13.447 28985 28985 I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
    04-08 16:05:13.447 28985 28985 I monodroid:   calling mono_class_get_image (0x7ce3fecb98)
    04-08 16:05:13.447 28985 28985 I monodroid:     image == 0x7ce3fecbc8
    04-08 16:05:13.447 28985 28985 I monodroid:     image_name == <null>

Case 1. would result in a segfault inside the `mono_image_get_name`
call, because the pointer value was clearly invalid, while case 2. would
result in a crash inside `strlen` which was passed a `null` pointer.

I found out that the root cause was in the `mono_type_get_class` call
which is supposed to be used with great caution as it eventually calls
the `mono_type_get_class_internal` function which is supposed to be
called only for object types `MONO_TYPE_CLASS` and `MONO_TYPE_VALUETYPE`
but not `MONO_TYPE_GENERICINST` type which is precisely the type that
caused the crash.  The fix is to call the `mono_class_from_mono_type`
function instead which, albeit slower, is safer and works correctly in
all cases.

Fixing this led to the next issue, a managed exception thrown after the
runtime failed to map managed type name to Java type name:

    04-08 18:08:58.886 30726 30726 W monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android'
    04-08 18:08:58.886 30726 30726 I monodroid-timing: Typemap.managed_to_java: end, total time; elapsed: 0s:0::33177
    04-08 18:08:58.888 30726 30726 D Mono    : DllImport attempting to load: '/system/lib64/liblog.so'.
    04-08 18:08:58.889 30726 30726 D Mono    : DllImport loaded library '/system/lib64/liblog.so'.
    04-08 18:08:58.889 30726 30726 D Mono    : DllImport searching in: '/system/lib64/liblog.so' ('/system/lib64/liblog.so').
    04-08 18:08:58.889 30726 30726 D Mono    : Searching for '__android_log_print'.
    04-08 18:08:58.889 30726 30726 D Mono    : Probing '__android_log_print'.
    04-08 18:08:58.889 30726 30726 D Mono    : Found as '__android_log_print'.
    04-08 18:08:58.891 30726 30726 I MonoDroid: UNHANDLED EXCEPTION:
    04-08 18:08:58.899 30726 30726 I MonoDroid: System.NotSupportedException: Cannot create instance of type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[[Xamarin.Forms.Page, Xamarin.Forms.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]]': no Java peer type found.
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods..ctor (System.Type declaringType) [0x0004b] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.GetConstructorsForType (System.Type declaringType) [0x00031] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.StartCreateInstance (System.String constructorSignature, System.Type declaringType, Java.Interop.JniArgumentValue* parameters) [0x00038] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Android.Support.V4.App.FragmentPagerAdapter..ctor (Android.Support.V4.App.FragmentManager fm) [0x0005b] in <fefee6c2c695459088a9df092723e052>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T]..ctor (Xamarin.Forms.MultiPage`1[T] page, Android.Support.V4.App.FragmentManager fragmentManager) [0x00000] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.CreateFormsViewPager (Android.Content.Context context, Xamarin.Forms.TabbedPage tabbedPage) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.OnElementChanged (Xamarin.Forms.Platform.Android.ElementChangedEventArgs`1[TElement] e) [0x001cd] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].SetElement (TElement element) [0x000c0] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Content.Context context) [0x0001f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.AddChild (Xamarin.Forms.Page page, System.Boolean layout) [0x0000d] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPageInternal (Xamarin.Forms.Page newRoot) [0x00061] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x000e6] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.InternalSetPage (Xamarin.Forms.Page page) [0x0003f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.SetMainPage () [0x0000c] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.LoadApplication (Xamarin.Forms.Application application) [0x00140] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at SwipeViewDemo.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) [0x00035] in <15e30af50bb64ff6b6d20ac6fd546763>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_savedInstanceState) [0x0000f] in <515e813169e54876823978ab785f569a>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.7(intptr,intptr,intptr)

Note that the type name as seen by the native code (via
`mono_get_type_name_full`) is
`Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T],
Xamarin.Forms.Platform.Android` while we should be looking for
`Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1`
instead.  The discrepancy was caused by calling
`mono_get_type_name_full` with its format parameter set to
`MONO_TYPE_NAME_FORMAT_REFLECTION`, while what we needed to do is to
pass it the format value of `MONO_TYPE_NAME_FORMAT_FULL_NAME` which this
commit implements.
grendello added a commit that referenced this pull request Apr 8, 2020
Context: 7117414

7117414 introduced native code which queries
the Mono runtime to obtain an instance of `MonoClass` for a given
`MonoReflectionType` as well as the `MonoImage` associated with the
class.  However, it appears that in certain cases the class pointer
stored `MonoReflectionType` doesn't lead us to getting a valid
`MonoImage` instance, causing a segfault similar to:

    04-08 15:52:55.015 19030 19030 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021 in tid 19030 (s.swipeviewdemo), pid 19030 (s.swipeviewdemo)
    04-08 15:52:55.037 19061 19061 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    04-08 15:52:55.037  1834  1834 I /system/bin/tombstoned: received crash request for pid 19030
    04-08 15:52:55.038 19061 19061 I crash_dump32: performing dump of process 19030 (target tid = 19030)
    04-08 15:52:55.042 19061 19061 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    04-08 15:52:55.042 19061 19061 F DEBUG   : Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.191030.002/5978551:userdebug/dev-keys'
    04-08 15:52:55.043 19061 19061 F DEBUG   : Revision: '0'
    04-08 15:52:55.043 19061 19061 F DEBUG   : ABI: 'x86'
    04-08 15:52:55.043 19061 19061 F DEBUG   : Timestamp: 2020-04-08 15:52:55+0200
    04-08 15:52:55.043 19061 19061 F DEBUG   : pid: 19030, tid: 19030, name: s.swipeviewdemo  >>> nl.versluis.swipeviewdemo <<<
    04-08 15:52:55.043 19061 19061 F DEBUG   : uid: 10135
    04-08 15:52:55.043 19061 19061 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021
    04-08 15:52:55.043 19061 19061 F DEBUG   :     eax 03000005  ebx cb9f4d24  ecx 7191c13b  edx 00000004
    04-08 15:52:55.043 19061 19061 F DEBUG   :     edi 03000005  esi ffb22080
    04-08 15:52:55.043 19061 19061 F DEBUG   :     ebp ffb22108  esp ffb2206c  eip cbcfc1e4
    04-08 15:52:55.077 19061 19061 F DEBUG   :
    04-08 15:52:55.077 19061 19061 F DEBUG   : backtrace:
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #00 pc 001b41e4  /data/app/Mono.Android.DebugRuntime-umHhDz421s4-tshrHwha0w==/lib/x86/libmonosgen-32bit-2.0.so (mono_image_get_name+4)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #1 pc 0000cac7  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoType*, _MonoClass*, unsigned char const*)+263) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #2 pc 0000c8cc  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+124) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       #3 pc 0001621a  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+42) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
    04-08 15:52:55.077 19061 19061 F DEBUG   :       dotnet#4 pc 000325af  <anonymous:c7858000>

Investigating the issue I discovered that one of two things happened:

  1. the returned `MonoImage` instance was invalid, or
  2. the instance was valid but image name stored in `MonoImage` was
     `null`

In case of 1. I would see something similar to this in the crash log:

    04-08 15:52:55.015 19030 19030 I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
    04-08 15:52:55.015 19030 19030 I monodroid:   type == 0xc6e60d3c, klass == 0xc6e60cb8, mvid == 0xc8c02d90
    04-08 15:52:55.015 19030 19030 I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
    04-08 15:52:55.015 19030 19030 I monodroid:   calling mono_class_get_image (0xc6e60cb8)
    04-08 15:52:55.015 19030 19030 I monodroid:     image == 0x3000005

It would happen in 32-bit builds only, the 64-bit builds would lead to a
different issue, the 2. above:

    04-08 16:05:13.446 28985 28985 I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
    04-08 16:05:13.447 28985 28985 I monodroid:   type == 0x7ce3fecc78, klass == 0x7ce3fecb98, mvid == 0x7ce9404520
    04-08 16:05:13.447 28985 28985 I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
    04-08 16:05:13.447 28985 28985 I monodroid:   calling mono_class_get_image (0x7ce3fecb98)
    04-08 16:05:13.447 28985 28985 I monodroid:     image == 0x7ce3fecbc8
    04-08 16:05:13.447 28985 28985 I monodroid:     image_name == <null>

Case 1. would result in a segfault inside the `mono_image_get_name`
call, because the pointer value was clearly invalid, while case 2. would
result in a crash inside `strlen` which was passed a `null` pointer.

I found out that the root cause was in the `mono_type_get_class` call
which is supposed to be used with great caution as it eventually calls
the `mono_type_get_class_internal` function which is supposed to be
called only for object types `MONO_TYPE_CLASS` and `MONO_TYPE_VALUETYPE`
but not `MONO_TYPE_GENERICINST` type which is precisely the type that
caused the crash.  The fix is to call the `mono_class_from_mono_type`
function instead which, albeit slower, is safer and works correctly in
all cases.

Fixing this led to the next issue, a managed exception thrown after the
runtime failed to map managed type name to Java type name:

    04-08 18:08:58.886 30726 30726 W monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android'
    04-08 18:08:58.886 30726 30726 I monodroid-timing: Typemap.managed_to_java: end, total time; elapsed: 0s:0::33177
    04-08 18:08:58.888 30726 30726 D Mono    : DllImport attempting to load: '/system/lib64/liblog.so'.
    04-08 18:08:58.889 30726 30726 D Mono    : DllImport loaded library '/system/lib64/liblog.so'.
    04-08 18:08:58.889 30726 30726 D Mono    : DllImport searching in: '/system/lib64/liblog.so' ('/system/lib64/liblog.so').
    04-08 18:08:58.889 30726 30726 D Mono    : Searching for '__android_log_print'.
    04-08 18:08:58.889 30726 30726 D Mono    : Probing '__android_log_print'.
    04-08 18:08:58.889 30726 30726 D Mono    : Found as '__android_log_print'.
    04-08 18:08:58.891 30726 30726 I MonoDroid: UNHANDLED EXCEPTION:
    04-08 18:08:58.899 30726 30726 I MonoDroid: System.NotSupportedException: Cannot create instance of type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[[Xamarin.Forms.Page, Xamarin.Forms.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]]': no Java peer type found.
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods..ctor (System.Type declaringType) [0x0004b] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.GetConstructorsForType (System.Type declaringType) [0x00031] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.StartCreateInstance (System.String constructorSignature, System.Type declaringType, Java.Interop.JniArgumentValue* parameters) [0x00038] in <514e1249792e47a180b3f1293306b972>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Android.Support.V4.App.FragmentPagerAdapter..ctor (Android.Support.V4.App.FragmentManager fm) [0x0005b] in <fefee6c2c695459088a9df092723e052>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T]..ctor (Xamarin.Forms.MultiPage`1[T] page, Android.Support.V4.App.FragmentManager fragmentManager) [0x00000] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.CreateFormsViewPager (Android.Content.Context context, Xamarin.Forms.TabbedPage tabbedPage) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.OnElementChanged (Xamarin.Forms.Platform.Android.ElementChangedEventArgs`1[TElement] e) [0x001cd] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].SetElement (TElement element) [0x000c0] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Content.Context context) [0x0001f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.AddChild (Xamarin.Forms.Page page, System.Boolean layout) [0x0000d] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPageInternal (Xamarin.Forms.Page newRoot) [0x00061] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x000e6] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.InternalSetPage (Xamarin.Forms.Page page) [0x0003f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.SetMainPage () [0x0000c] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.LoadApplication (Xamarin.Forms.Application application) [0x00140] in <9d12bb15abb54c508c4bee636d1b3a42>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at SwipeViewDemo.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) [0x00035] in <15e30af50bb64ff6b6d20ac6fd546763>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_savedInstanceState) [0x0000f] in <515e813169e54876823978ab785f569a>:0
    04-08 18:08:58.899 30726 30726 I MonoDroid:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.7(intptr,intptr,intptr)

Note that the type name as seen by the native code (via
`mono_get_type_name_full`) is
`Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T],
Xamarin.Forms.Platform.Android` while we should be looking for
`Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1`
instead.  The discrepancy was caused by calling
`mono_get_type_name_full` with its format parameter set to
`MONO_TYPE_NAME_FORMAT_REFLECTION`, while what we needed to do is to
pass it the format value of `MONO_TYPE_NAME_FORMAT_FULL_NAME` which this
commit implements.
grendello added a commit that referenced this pull request Apr 14, 2020
Context: https://github.com/jfversluis/SwipeViewDemo
Context: https://github.com/xamarin/Xamarin.Forms/blob/fa33ca3b3ac5c7c875023db785b56c67015e13b1/Xamarin.Forms.Platform.Android/AppCompat/TabbedPageRenderer.cs#L512

Commit 7117414 introduced native code which queries the Mono runtime
to obtain an instance of a `MonoClass` for a given `MonoReflectionType`
as well as the `MonoImage` associated with the `MonoClass`:

	// EmbeddedAssemblies::typemap_managed_to_java(MonoReflectionType *reflection_type, const uint8_t *mvid)
	MonoReflectionType     *reflection_type = …
	MonoType               *type            = mono_reflection_type_get_type (reflection_type);
	MonoClass              *klass           = mono_type_get_class (type);   // PROBLEMATIC
	// EmbeddedAssemblies::typemap_managed_to_java(MonoType *type, MonoClass *klass, const uint8_t *mvid)
	MonoImage              *image           = mono_class_get_image (klass);

However, it appears that when dealing with closed generic types -- such
as with `new GenericHolder<int>()` -- the above call chain results in a
SIGSEGV instead of a valid `MonoImage*`:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021 in tid 19030 (s.swipeviewdemo), pid 19030 (s.swipeviewdemo)
	I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	I /system/bin/tombstoned: received crash request for pid 19030
	I crash_dump32: performing dump of process 19030 (target tid = 19030)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.191030.002/5978551:userdebug/dev-keys'
	F DEBUG   : Revision: '0'
	F DEBUG   : ABI: 'x86'
	F DEBUG   : Timestamp: 2020-04-08 15:52:55+0200
	F DEBUG   : pid: 19030, tid: 19030, name: s.swipeviewdemo  >>> nl.versluis.swipeviewdemo <<<
	F DEBUG   : uid: 10135
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021
	F DEBUG   :     eax 03000005  ebx cb9f4d24  ecx 7191c13b  edx 00000004
	F DEBUG   :     edi 03000005  esi ffb22080
	F DEBUG   :     ebp ffb22108  esp ffb2206c  eip cbcfc1e4
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :       #00 pc 001b41e4  /data/app/Mono.Android.DebugRuntime-umHhDz421s4-tshrHwha0w==/lib/x86/libmonosgen-32bit-2.0.so (mono_image_get_name+4)
	F DEBUG   :       #1 pc 0000cac7  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoType*, _MonoClass*, unsigned char const*)+263) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       #2 pc 0000c8cc  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+124) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       #3 pc 0001621a  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+42) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       dotnet#4 pc 000325af  <anonymous:c7858000>

Investigating the issue I discovered that one of two things happened:

 1. the returned `MonoImage` instance was invalid, *or*
 2. the instance was valid but image name stored in `MonoImage`
    was `null`

(1) would only happen in 32-bit builds, resulting in a SIGSEGV within
`mono_image_get_name()`, because the `image` pointer value of 0x3000005
was invalid:

	I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
	I monodroid:   type == 0xc6e60d3c, klass == 0xc6e60cb8, mvid == 0xc8c02d90
	I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
	I monodroid:   calling mono_class_get_image (0xc6e60cb8)
	I monodroid:     image == 0x3000005

(2) only happened in 64-bit builds, resulting in a SIGSEGV as
`strlen()` was passed a `null` pointer:

	I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
	I monodroid:   type == 0x7ce3fecc78, klass == 0x7ce3fecb98, mvid == 0x7ce9404520
	I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
	I monodroid:   calling mono_class_get_image (0x7ce3fecb98)
	I monodroid:     image == 0x7ce3fecbc8
	I monodroid:     image_name == <null>

I found out that the root cause was in the `mono_type_get_class()` call
which is supposed to be used with great caution as it eventually calls
the `mono_type_get_class_internal()` function which is supposed to be
called only for object types `MONO_TYPE_CLASS` and `MONO_TYPE_VALUETYPE`
but not `MONO_TYPE_GENERICINST`, and `MONO_TYPE_GENERICINST` is used
for closed generic types.

The fix is to call the `mono_class_from_mono_type()` function instead
which, albeit slower, is safer and works correctly in all cases:

	// EmbeddedAssemblies::typemap_managed_to_java(MonoReflectionType *reflection_type, const uint8_t *mvid)
	MonoReflectionType     *reflection_type = …
	MonoType               *type            = mono_reflection_type_get_type (reflection_type);
	MonoClass              *klass           = mono_class_from_mono_type (type);     // PART OF THE FIX
	// EmbeddedAssemblies::typemap_managed_to_java(MonoType *type, MonoClass *klass, const uint8_t *mvid)
	MonoImage              *image           = mono_class_get_image (klass)

Fixing this led to the next issue, a managed exception thrown after the
runtime failed to map a managed type name to Java type name:

	W monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android'
	I monodroid-timing: Typemap.managed_to_java: end, total time; elapsed: 0s:0::33177
	D Mono    : DllImport attempting to load: '/system/lib64/liblog.so'.
	D Mono    : DllImport loaded library '/system/lib64/liblog.so'.
	D Mono    : DllImport searching in: '/system/lib64/liblog.so' ('/system/lib64/liblog.so').
	D Mono    : Searching for '__android_log_print'.
	D Mono    : Probing '__android_log_print'.
	D Mono    : Found as '__android_log_print'.
	I MonoDroid: UNHANDLED EXCEPTION:
	I MonoDroid: System.NotSupportedException: Cannot create instance of type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[[Xamarin.Forms.Page, Xamarin.Forms.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]]': no Java peer type found.
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods..ctor (System.Type declaringType) [0x0004b] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.GetConstructorsForType (System.Type declaringType) [0x00031] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.StartCreateInstance (System.String constructorSignature, System.Type declaringType, Java.Interop.JniArgumentValue* parameters) [0x00038] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Android.Support.V4.App.FragmentPagerAdapter..ctor (Android.Support.V4.App.FragmentManager fm) [0x0005b] in <fefee6c2c695459088a9df092723e052>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T]..ctor (Xamarin.Forms.MultiPage`1[T] page, Android.Support.V4.App.FragmentManager fragmentManager) [0x00000] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.CreateFormsViewPager (Android.Content.Context context, Xamarin.Forms.TabbedPage tabbedPage) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.OnElementChanged (Xamarin.Forms.Platform.Android.ElementChangedEventArgs`1[TElement] e) [0x001cd] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].SetElement (TElement element) [0x000c0] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Content.Context context) [0x0001f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.AddChild (Xamarin.Forms.Page page, System.Boolean layout) [0x0000d] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPageInternal (Xamarin.Forms.Page newRoot) [0x00061] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x000e6] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.InternalSetPage (Xamarin.Forms.Page page) [0x0003f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.SetMainPage () [0x0000c] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.LoadApplication (Xamarin.Forms.Application application) [0x00140] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at SwipeViewDemo.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) [0x00035] in <15e30af50bb64ff6b6d20ac6fd546763>:0
	I MonoDroid:   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_savedInstanceState) [0x0000f] in <515e813169e54876823978ab785f569a>:0
	I MonoDroid:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.7(intptr,intptr,intptr)

Note that the type name as seen by the native code via
`mono_get_type_name_full()` is:

	Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android

while `Mono.Android.dll` expects to be looking for:

	Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1, Xamarin.Forms.Platform.Android

This discrepancy was caused by calling `mono_get_type_name_full()`
with its format parameter set to `MONO_TYPE_NAME_FORMAT_REFLECTION`,
while we needed the format value of `MONO_TYPE_NAME_FORMAT_FULL_NAME`.
grendello added a commit that referenced this pull request May 11, 2020
Fixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf

A missing parameter in a call to `log_debug` added in a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:

		F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
		I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
		I /system/bin/tombstoned: received crash request for pid 922
		I crash_dump64: performing dump of process 922 (target tid = 922)
		F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
		F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
		F DEBUG   : Revision: '0'
		F DEBUG   : ABI: 'x86_64'
		F DEBUG   : pid: 922, tid: 922, name: DrawableTinting  >>> com.xamarin.DrawableTinting <<<
		F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
		F DEBUG   : Cause: null pointer dereference
		F DEBUG   :     rax 0000000000000000  rbx 00007ffed3c283c0  rcx 0000000000000003  rdx 0000000000000002
		F DEBUG   :     r8  00007ffed3c283c0  r9  00000000ffffffff  r10 00007ffed3c283d0  r11 00007ffed3c28824
		F DEBUG   :     r12 00007c88774a2f17  r13 00000000ffffffff  r14 0000000000000000  r15 00007ffed3c283d0
		F DEBUG   :     rdi 0000000000000003  rsi 00007ffed3c283bb
		F DEBUG   :     rbp 00007ffed3c28f18  rsp 00007ffed3c28288  rip 00007c890f860761
		F DEBUG   :
		F DEBUG   : backtrace:
		F DEBUG   :     #00 pc 0000000000020761  /system/lib64/libc.so (strlen+17)
		F DEBUG   :     #1 pc 000000000006e761  /system/lib64/libc.so (__vfprintf+5953)
		F DEBUG   :     #2 pc 000000000008df5d  /system/lib64/libc.so (vsnprintf+189)
		F DEBUG   :     #3 pc 0000000000007b60  /system/lib64/liblog.so (__android_log_vprint+64)
		F DEBUG   :     dotnet#4 pc 000000000001350c  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
		F DEBUG   :     dotnet#5 pc 000000000000de6a  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
		F DEBUG   :     dotnet#6 pc 000000000000df13  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
		F DEBUG   :     dotnet#7 pc 00000000000d57f8  <anonymous:0000000042d04000>

Add the missing parameter to prevent the `SIGSEGV` from happening.
grendello added a commit that referenced this pull request May 12, 2020
…otnet#4673)

Fixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf

A missing parameter in a call to `log_debug` added iFixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf

A missing parameter in a call to `log_debug()` added in a017561 may
lead to a segfault when `assembly` log category and `debug` log level
are enabled:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
	I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	I /system/bin/tombstoned: received crash request for pid 922
	I crash_dump64: performing dump of process 922 (target tid = 922)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
	F DEBUG   : Revision: '0'
	F DEBUG   : ABI: 'x86_64'
	F DEBUG   : pid: 922, tid: 922, name: DrawableTinting  >>> com.xamarin.DrawableTinting <<<
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
	F DEBUG   : Cause: null pointer dereference
	F DEBUG   :     rax 0000000000000000  rbx 00007ffed3c283c0  rcx 0000000000000003  rdx 0000000000000002
	F DEBUG   :     r8  00007ffed3c283c0  r9  00000000ffffffff  r10 00007ffed3c283d0  r11 00007ffed3c28824
	F DEBUG   :     r12 00007c88774a2f17  r13 00000000ffffffff  r14 0000000000000000  r15 00007ffed3c283d0
	F DEBUG   :     rdi 0000000000000003  rsi 00007ffed3c283bb
	F DEBUG   :     rbp 00007ffed3c28f18  rsp 00007ffed3c28288  rip 00007c890f860761
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 0000000000020761  /system/lib64/libc.so (strlen+17)
	F DEBUG   :     #1 pc 000000000006e761  /system/lib64/libc.so (__vfprintf+5953)
	F DEBUG   :     #2 pc 000000000008df5d  /system/lib64/libc.so (vsnprintf+189)
	F DEBUG   :     #3 pc 0000000000007b60  /system/lib64/liblog.so (__android_log_vprint+64)
	F DEBUG   :     dotnet#4 pc 000000000001350c  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
	F DEBUG   :     dotnet#5 pc 000000000000de6a  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
	F DEBUG   :     dotnet#6 pc 000000000000df13  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
	F DEBUG   :     dotnet#7 pc 00000000000d57f8  <anonymous:0000000042d04000>

Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:

		F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
		I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
		I /system/bin/tombstoned: received crash request for pid 922
		I crash_dump64: performing dump of process 922 (target tid = 922)
		F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
		F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
		F DEBUG   : Revision: '0'
		F DEBUG   : ABI: 'x86_64'
		F DEBUG   : pid: 922, tid: 922, name: DrawableTinting  >>> com.xamarin.DrawableTinting <<<
		F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
		F DEBUG   : Cause: null pointer dereference
		F DEBUG   :     rax 0000000000000000  rbx 00007ffed3c283c0  rcx 0000000000000003  rdx 0000000000000002
		F DEBUG   :     r8  00007ffed3c283c0  r9  00000000ffffffff  r10 00007ffed3c283d0  r11 00007ffed3c28824
		F DEBUG   :     r12 00007c88774a2f17  r13 00000000ffffffff  r14 0000000000000000  r15 00007ffed3c283d0
		F DEBUG   :     rdi 0000000000000003  rsi 00007ffed3c283bb
		F DEBUG   :     rbp 00007ffed3c28f18  rsp 00007ffed3c28288  rip 00007c890f860761
		F DEBUG   :
		F DEBUG   : backtrace:
		F DEBUG   :     #00 pc 0000000000020761  /system/lib64/libc.so (strlen+17)
		F DEBUG   :     #1 pc 000000000006e761  /system/lib64/libc.so (__vfprintf+5953)
		F DEBUG   :     #2 pc 000000000008df5d  /system/lib64/libc.so (vsnprintf+189)
		F DEBUG   :     #3 pc 0000000000007b60  /system/lib64/liblog.so (__android_log_vprint+64)
		F DEBUG   :     dotnet#4 pc 000000000001350c  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
		F DEBUG   :     dotnet#5 pc 000000000000de6a  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
		F DEBUG   :     dotnet#6 pc 000000000000df13  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
		F DEBUG   :     dotnet#7 pc 00000000000d57f8  <anonymous:0000000042d04000>

Add the missing parameter to prevent the `SIGSEGV` from happening.
grendello added a commit that referenced this pull request 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 added a commit that referenced this pull request 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)
grendello added a commit that referenced this pull request May 27, 2020
Fixes: dotnet#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   :       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.
grendello added a commit that referenced this pull request Jun 5, 2020
Context: https://github.com/jfversluis/SwipeViewDemo
Context: https://github.com/xamarin/Xamarin.Forms/blob/fa33ca3b3ac5c7c875023db785b56c67015e13b1/Xamarin.Forms.Platform.Android/AppCompat/TabbedPageRenderer.cs#L512

Commit 7117414 introduced native code which queries the Mono runtime
to obtain an instance of a `MonoClass` for a given `MonoReflectionType`
as well as the `MonoImage` associated with the `MonoClass`:

	// EmbeddedAssemblies::typemap_managed_to_java(MonoReflectionType *reflection_type, const uint8_t *mvid)
	MonoReflectionType     *reflection_type = …
	MonoType               *type            = mono_reflection_type_get_type (reflection_type);
	MonoClass              *klass           = mono_type_get_class (type);   // PROBLEMATIC
	// EmbeddedAssemblies::typemap_managed_to_java(MonoType *type, MonoClass *klass, const uint8_t *mvid)
	MonoImage              *image           = mono_class_get_image (klass);

However, it appears that when dealing with closed generic types -- such
as with `new GenericHolder<int>()` -- the above call chain results in a
SIGSEGV instead of a valid `MonoImage*`:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021 in tid 19030 (s.swipeviewdemo), pid 19030 (s.swipeviewdemo)
	I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	I /system/bin/tombstoned: received crash request for pid 19030
	I crash_dump32: performing dump of process 19030 (target tid = 19030)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.191030.002/5978551:userdebug/dev-keys'
	F DEBUG   : Revision: '0'
	F DEBUG   : ABI: 'x86'
	F DEBUG   : Timestamp: 2020-04-08 15:52:55+0200
	F DEBUG   : pid: 19030, tid: 19030, name: s.swipeviewdemo  >>> nl.versluis.swipeviewdemo <<<
	F DEBUG   : uid: 10135
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3000021
	F DEBUG   :     eax 03000005  ebx cb9f4d24  ecx 7191c13b  edx 00000004
	F DEBUG   :     edi 03000005  esi ffb22080
	F DEBUG   :     ebp ffb22108  esp ffb2206c  eip cbcfc1e4
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :       #00 pc 001b41e4  /data/app/Mono.Android.DebugRuntime-umHhDz421s4-tshrHwha0w==/lib/x86/libmonosgen-32bit-2.0.so (mono_image_get_name+4)
	F DEBUG   :       #1 pc 0000cac7  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoType*, _MonoClass*, unsigned char const*)+263) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       #2 pc 0000c8cc  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+124) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       #3 pc 0001621a  /data/app/nl.versluis.swipeviewdemo-jCFH_bcCNuFx1tLUhaJ4nw==/lib/x86/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::typemap_managed_to_java(_MonoReflectionType*, unsigned char const*)+42) (BuildId: a2585ad379f788049e463af58c8686e9cdc1e778)
	F DEBUG   :       dotnet#4 pc 000325af  <anonymous:c7858000>

Investigating the issue I discovered that one of two things happened:

 1. the returned `MonoImage` instance was invalid, *or*
 2. the instance was valid but image name stored in `MonoImage`
    was `null`

(1) would only happen in 32-bit builds, resulting in a SIGSEGV within
`mono_image_get_name()`, because the `image` pointer value of 0x3000005
was invalid:

	I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
	I monodroid:   type == 0xc6e60d3c, klass == 0xc6e60cb8, mvid == 0xc8c02d90
	I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
	I monodroid:   calling mono_class_get_image (0xc6e60cb8)
	I monodroid:     image == 0x3000005

(2) only happened in 64-bit builds, resulting in a SIGSEGV as
`strlen()` was passed a `null` pointer:

	I monodroid: const char *xamarin::android::internal::EmbeddedAssemblies::typemap_managed_to_java(MonoType *, MonoClass *, const uint8_t *)
	I monodroid:   type == 0x7ce3fecc78, klass == 0x7ce3fecb98, mvid == 0x7ce9404520
	I monodroid:   type name == Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[Xamarin.Forms.Page]
	I monodroid:   calling mono_class_get_image (0x7ce3fecb98)
	I monodroid:     image == 0x7ce3fecbc8
	I monodroid:     image_name == <null>

I found out that the root cause was in the `mono_type_get_class()` call
which is supposed to be used with great caution as it eventually calls
the `mono_type_get_class_internal()` function which is supposed to be
called only for object types `MONO_TYPE_CLASS` and `MONO_TYPE_VALUETYPE`
but not `MONO_TYPE_GENERICINST`, and `MONO_TYPE_GENERICINST` is used
for closed generic types.

The fix is to call the `mono_class_from_mono_type()` function instead
which, albeit slower, is safer and works correctly in all cases:

	// EmbeddedAssemblies::typemap_managed_to_java(MonoReflectionType *reflection_type, const uint8_t *mvid)
	MonoReflectionType     *reflection_type = …
	MonoType               *type            = mono_reflection_type_get_type (reflection_type);
	MonoClass              *klass           = mono_class_from_mono_type (type);     // PART OF THE FIX
	// EmbeddedAssemblies::typemap_managed_to_java(MonoType *type, MonoClass *klass, const uint8_t *mvid)
	MonoImage              *image           = mono_class_get_image (klass)

Fixing this led to the next issue, a managed exception thrown after the
runtime failed to map a managed type name to Java type name:

	W monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android'
	I monodroid-timing: Typemap.managed_to_java: end, total time; elapsed: 0s:0::33177
	D Mono    : DllImport attempting to load: '/system/lib64/liblog.so'.
	D Mono    : DllImport loaded library '/system/lib64/liblog.so'.
	D Mono    : DllImport searching in: '/system/lib64/liblog.so' ('/system/lib64/liblog.so').
	D Mono    : Searching for '__android_log_print'.
	D Mono    : Probing '__android_log_print'.
	D Mono    : Found as '__android_log_print'.
	I MonoDroid: UNHANDLED EXCEPTION:
	I MonoDroid: System.NotSupportedException: Cannot create instance of type 'Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[[Xamarin.Forms.Page, Xamarin.Forms.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null]]': no Java peer type found.
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods..ctor (System.Type declaringType) [0x0004b] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.GetConstructorsForType (System.Type declaringType) [0x00031] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Java.Interop.JniPeerMembers+JniInstanceMethods.StartCreateInstance (System.String constructorSignature, System.Type declaringType, Java.Interop.JniArgumentValue* parameters) [0x00038] in <514e1249792e47a180b3f1293306b972>:0
	I MonoDroid:   at Android.Support.V4.App.FragmentPagerAdapter..ctor (Android.Support.V4.App.FragmentManager fm) [0x0005b] in <fefee6c2c695459088a9df092723e052>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T]..ctor (Xamarin.Forms.MultiPage`1[T] page, Android.Support.V4.App.FragmentManager fragmentManager) [0x00000] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.CreateFormsViewPager (Android.Content.Context context, Xamarin.Forms.TabbedPage tabbedPage) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.TabbedPageRenderer.OnElementChanged (Xamarin.Forms.Platform.Android.ElementChangedEventArgs`1[TElement] e) [0x001cd] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].SetElement (TElement element) [0x000c0] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.VisualElementRenderer`1[TElement].Xamarin.Forms.Platform.Android.IVisualElementRenderer.SetElement (Xamarin.Forms.VisualElement element) [0x00033] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.Platform.CreateRenderer (Xamarin.Forms.VisualElement element, Android.Content.Context context) [0x0001f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.AddChild (Xamarin.Forms.Page page, System.Boolean layout) [0x0000d] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPageInternal (Xamarin.Forms.Page newRoot) [0x00061] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.AppCompat.Platform.SetPage (Xamarin.Forms.Page newRoot) [0x000e6] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.InternalSetPage (Xamarin.Forms.Page page) [0x0003f] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.SetMainPage () [0x0000c] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at Xamarin.Forms.Platform.Android.FormsAppCompatActivity.LoadApplication (Xamarin.Forms.Application application) [0x00140] in <9d12bb15abb54c508c4bee636d1b3a42>:0
	I MonoDroid:   at SwipeViewDemo.Droid.MainActivity.OnCreate (Android.OS.Bundle savedInstanceState) [0x00035] in <15e30af50bb64ff6b6d20ac6fd546763>:0
	I MonoDroid:   at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_ (System.IntPtr jnienv, System.IntPtr native__this, System.IntPtr native_savedInstanceState) [0x0000f] in <515e813169e54876823978ab785f569a>:0
	I MonoDroid:   at (wrapper dynamic-method) Android.Runtime.DynamicMethodNameCounter.7(intptr,intptr,intptr)

Note that the type name as seen by the native code via
`mono_get_type_name_full()` is:

	Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1[T], Xamarin.Forms.Platform.Android

while `Mono.Android.dll` expects to be looking for:

	Xamarin.Forms.Platform.Android.AppCompat.FormsFragmentPagerAdapter`1, Xamarin.Forms.Platform.Android

This discrepancy was caused by calling `mono_get_type_name_full()`
with its format parameter set to `MONO_TYPE_NAME_FORMAT_REFLECTION`,
while we needed the format value of `MONO_TYPE_NAME_FORMAT_FULL_NAME`.
grendello added a commit that referenced this pull request Jun 5, 2020
…otnet#4673)

Fixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf

A missing parameter in a call to `log_debug` added iFixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf

A missing parameter in a call to `log_debug()` added in a017561 may
lead to a segfault when `assembly` log category and `debug` log level
are enabled:

	F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
	I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
	I /system/bin/tombstoned: received crash request for pid 922
	I crash_dump64: performing dump of process 922 (target tid = 922)
	F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
	F DEBUG   : Revision: '0'
	F DEBUG   : ABI: 'x86_64'
	F DEBUG   : pid: 922, tid: 922, name: DrawableTinting  >>> com.xamarin.DrawableTinting <<<
	F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
	F DEBUG   : Cause: null pointer dereference
	F DEBUG   :     rax 0000000000000000  rbx 00007ffed3c283c0  rcx 0000000000000003  rdx 0000000000000002
	F DEBUG   :     r8  00007ffed3c283c0  r9  00000000ffffffff  r10 00007ffed3c283d0  r11 00007ffed3c28824
	F DEBUG   :     r12 00007c88774a2f17  r13 00000000ffffffff  r14 0000000000000000  r15 00007ffed3c283d0
	F DEBUG   :     rdi 0000000000000003  rsi 00007ffed3c283bb
	F DEBUG   :     rbp 00007ffed3c28f18  rsp 00007ffed3c28288  rip 00007c890f860761
	F DEBUG   :
	F DEBUG   : backtrace:
	F DEBUG   :     #00 pc 0000000000020761  /system/lib64/libc.so (strlen+17)
	F DEBUG   :     #1 pc 000000000006e761  /system/lib64/libc.so (__vfprintf+5953)
	F DEBUG   :     #2 pc 000000000008df5d  /system/lib64/libc.so (vsnprintf+189)
	F DEBUG   :     #3 pc 0000000000007b60  /system/lib64/liblog.so (__android_log_vprint+64)
	F DEBUG   :     dotnet#4 pc 000000000001350c  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
	F DEBUG   :     dotnet#5 pc 000000000000de6a  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
	F DEBUG   :     dotnet#6 pc 000000000000df13  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
	F DEBUG   :     dotnet#7 pc 00000000000d57f8  <anonymous:0000000042d04000>

Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:

		F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
		I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
		I /system/bin/tombstoned: received crash request for pid 922
		I crash_dump64: performing dump of process 922 (target tid = 922)
		F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
		F DEBUG   : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
		F DEBUG   : Revision: '0'
		F DEBUG   : ABI: 'x86_64'
		F DEBUG   : pid: 922, tid: 922, name: DrawableTinting  >>> com.xamarin.DrawableTinting <<<
		F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
		F DEBUG   : Cause: null pointer dereference
		F DEBUG   :     rax 0000000000000000  rbx 00007ffed3c283c0  rcx 0000000000000003  rdx 0000000000000002
		F DEBUG   :     r8  00007ffed3c283c0  r9  00000000ffffffff  r10 00007ffed3c283d0  r11 00007ffed3c28824
		F DEBUG   :     r12 00007c88774a2f17  r13 00000000ffffffff  r14 0000000000000000  r15 00007ffed3c283d0
		F DEBUG   :     rdi 0000000000000003  rsi 00007ffed3c283bb
		F DEBUG   :     rbp 00007ffed3c28f18  rsp 00007ffed3c28288  rip 00007c890f860761
		F DEBUG   :
		F DEBUG   : backtrace:
		F DEBUG   :     #00 pc 0000000000020761  /system/lib64/libc.so (strlen+17)
		F DEBUG   :     #1 pc 000000000006e761  /system/lib64/libc.so (__vfprintf+5953)
		F DEBUG   :     #2 pc 000000000008df5d  /system/lib64/libc.so (vsnprintf+189)
		F DEBUG   :     #3 pc 0000000000007b60  /system/lib64/liblog.so (__android_log_vprint+64)
		F DEBUG   :     dotnet#4 pc 000000000001350c  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
		F DEBUG   :     dotnet#5 pc 000000000000de6a  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
		F DEBUG   :     dotnet#6 pc 000000000000df13  /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
		F DEBUG   :     dotnet#7 pc 00000000000d57f8  <anonymous:0000000042d04000>

Add the missing parameter to prevent the `SIGSEGV` from happening.
grendello added a commit that referenced this pull request Jun 5, 2020
Fixes: dotnet#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   :       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.
grendello pushed a commit that referenced this pull request Feb 10, 2021
Changes: xamarin/NRefactory@0607a4a...495405a

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

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

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

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

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

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

[0]: https://github.com/icsharpcode/NRefactory
[1]: https://github.com/xamarin/NRefactory
grendello added a commit that referenced this pull request 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 added a commit that referenced this pull request 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.
grendello added a commit that referenced this pull request Feb 18, 2021
…otnet#5623)

Context: dotnet#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 pushed a commit that referenced this pull request May 28, 2021
)

Changes: dotnet/installer@f442964...3ebe0ca
Changes: dotnet/linker@7a5c445...620b243
Changes: dotnet/runtime@6430375...5a26d12

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

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

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

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

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

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

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

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

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

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

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

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

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

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Jonathan Peppers <[email protected]>
Co-authored-by: Peter Collins <[email protected]>
 
[0]: dotnet/installer@f442964...3ebe0ca
[1]: dotnet/linker@7a5c445...620b243
[2]: dotnet/runtime@6430375...5a26d12
[3]: https://github.com/dotnet/sdk/blob/1f544a59270cecb2947e50a01f7056c685b4e319/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L389-L392
grendello added a commit that referenced this pull request 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@[email protected][email protected]@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.
grendello added a commit that referenced this pull request Nov 2, 2021
)

Context: dotnet#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:     dotnet#4 0xaef009ae  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
	Mono.Android_Tests:     dotnet#5 0xaef06d14  (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
	Mono.Android_Tests:     dotnet#6 0xb30cb970  (/data/dalvik-cache/x86/data@[email protected][email protected]@classes.dex+0x5c970)
	Mono.Android_Tests: SUMMARY: AddressSanitizer: heap-buffer-overflow (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)

Address of the offending region points to
`BasicUtilities::monodroid_strsplit()` and is likely the line
modified in this commit.  Append terminating `nullptr` to `vector`
instead of overwriting the last element.
grendello 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.
grendello pushed a commit that referenced this pull request Jan 28, 2022
…6672)

Context: dotnet/maui#4262
Context: dotnet#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   : dotnet#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
dotnet#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
grendello added 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
grendello added a commit that referenced this pull request Sep 15, 2022
    9-15 22:56:28.431 15070 15090 W monodroid: jclass java_interop_jnienv_find_class(JNIEnv *, jthrowable *, const char *) looking for 'android/content/Intent$ShortcutIconResource'
    --------- beginning of crash
    09-15 22:56:28.432 15070 15090 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbb60ca20 in tid 15090 (Instrumentation), pid 15070 (droid.NET_Tests)
    09-15 22:56:28.757 15103 15103 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    09-15 22:56:28.757 15103 15103 F DEBUG   : Build fingerprint: 'google/raven/raven:13/TP1A.220624.021/8877034:user/release-keys'
    09-15 22:56:28.757 15103 15103 F DEBUG   : Revision: 'MP1.0'
    09-15 22:56:28.757 15103 15103 F DEBUG   : ABI: 'arm64'
    09-15 22:56:28.757 15103 15103 F DEBUG   : Timestamp: 2022-09-15 22:56:28.545823727+0200
    09-15 22:56:28.757 15103 15103 F DEBUG   : Process uptime: 3s
    09-15 22:56:28.757 15103 15103 F DEBUG   : Cmdline: Mono.Android.NET_Tests
    09-15 22:56:28.757 15103 15103 F DEBUG   : pid: 15070, tid: 15090, name: Instrumentation  >>> Mono.Android.NET_Tests <<<
    09-15 22:56:28.757 15103 15103 F DEBUG   : uid: 10638
    09-15 22:56:28.757 15103 15103 F DEBUG   : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
    09-15 22:56:28.757 15103 15103 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x00000000bb60ca20
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x0  b400006e8ea08350  x1  0000000000000001  x2  0000000000000001  x3  0000000000000010
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x4  0000006dbaea7233  x5  0000006deea682be  x6  0000000000000020  x7  0000000000000020
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x8  0000000000000008  x9  00000000bb60c9e0  x10 0000006deea682a7  x11 0000006deea682a7
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x12 3d2120746e696f70  x13 7274706c6c756e20  x14 0000006d3d90b998  x15 000000a74ab3008e
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x16 0000006dbb60f6b8  x17 0000007074e7b9ac  x18 0000006d394cc000  x19 0000006d3d90b6d8
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x20 b400006e8ea08350  x21 0000000000000001  x22 0000006d3d90e000  x23 0000006d3d90b6d8
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x24 0000006d3d90b830  x25 0000006d3d90bb80  x26 0000006e7ea14cf0  x27 b400006e8ea08350
    09-15 22:56:28.757 15103 15103 F DEBUG   :     x28 0000000000000000  x29 0000006d3d90b5d0
    09-15 22:56:28.757 15103 15103 F DEBUG   :     lr  0000006dbb16f3dc  sp  0000006d3d90b5b0  pc  0000006dbb171d44  pst 0000000080001000
    09-15 22:56:28.757 15103 15103 F DEBUG   : backtrace:
    09-15 22:56:28.757 15103 15103 F DEBUG   :       #00 pc 0000000000371d44  /apex/com.android.art/lib64/libart.so (art::ArtMethod::PrettyMethod(bool)+76) (BuildId: 56e704c544e6c624201be2ab4933e853)
    09-15 22:56:28.757 15103 15103 F DEBUG   :       #1 pc 000000000036f3d8  /apex/com.android.art/lib64/libart.so (void art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+5464) (BuildId: 56e704c544e6c624201be2ab4933e853)
    09-15 22:56:28.757 15103 15103 F DEBUG   :       #2 pc 00000000005a0370  /apex/com.android.art/lib64/libart.so (art::JNI<true>::FindClass(_JNIEnv*, char const*)+480) (BuildId: 56e704c544e6c624201be2ab4933e853)
    09-15 22:56:28.757 15103 15103 F DEBUG   :       #3 pc 00000000005c8948  /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::FindClass(_JNIEnv*, char const*) (.__uniq.99033978352804627313491551960229047428.llvm.5591279935177935698)+228) (BuildId: 56e704c544e6c624201be2ab4933e853)
    09-15 22:56:28.757 15103 15103 F DEBUG   :       dotnet#4 pc 000000000004de28  /data/app/~~aJedheWQLPfk1ulUOfKVyg==/Mono.Android.NET_Tests-XvAL5W7BvZDwkEbYfmLTIQ==/lib/arm64/libmonodroid.so (java_interop_jnienv_find_class+84) (BuildId: a92c56b31adcb233a4674b5eb523c0aaa67a811d)
    09-15 22:56:28.757 15103 15103 F DEBUG   :       dotnet#5 pc 000000000000b220  <anonymous:705fcb1000>
grendello added a commit that referenced this pull request Nov 22, 2022
It won't fix the failure, but extra logging might be useful at some
point. The current failure is:

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

Updates:

* Microsoft.Dotnet.Sdk.Internal: from 8.0.100-alpha.1.23063.11 to 8.0.100-alpha.1.23070.23
* Microsoft.NET.ILLink.Tasks: from 8.0.100-1.23055.2 to 8.0.100-1.23067.1
* Microsoft.NETCore.App.Ref: from 8.0.0-alpha.1.23058.2 to 8.0.0-alpha.1.23070.1
* Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100: from 8.0.0-alpha.1.22620.1 to 8.0.0-alpha.1.23066.1

~~ Other Changes ~~

* Update `.apkdesc` files for app size changes.

* Use .jar files from the .NET runtime pack (dotnet#7665)

Since [dotnet/runtime#77386][0] has been merged, .NET will require
a certain class from  `libSystem.Security.Cryptography.Native.Android.jar`
that will be located in the runtime pack files.

[0]: dotnet/runtime#77386

* Disambiguate `.jar` files from Mono runtime packs.

We were getting the build error:

    error JAVA0000: Caused by: com.android.tools.r8.internal.f: Type net.dot.android.crypto.DotnetProxyTrustManager is defined multiple times

This `.jar` file is contained in each runtime pack (4 architectures)
gives us 4 `.jar` files!

We can pass in these files to the `<ProcessAssemblies/>` MSBuild task.

We also filter them based on `%(NuGetPackageId)`, so that any random
`.jar` file doesn't get added to `@(AndroidJavaLibrary)`.

I renamed the `IsFrameworkAssembly()` method to
`IsFromAKnownRuntimePack()` to make this more clear in the existing
code.

* Update `proguard_xamarin.cfg` for .NET 8.

Apps using `$(AndroidLinkTool)` of r8, now need to preserve:

    -keep class net.dot.android.crypto.DotnetProxyTrustManager { *; <init>(...); }

Otherwise we run into a crash when this type isn't present, such as:

    01-26 23:59:19.855  8684  8684 F DEBUG   :       #2 pc 00000000000191d6  /data/app/Mono.Android.NET_Tests-cpTzt8Q9KwgS-znzkuAdNQ==/split_config.x86_64.apk!libSystem.Security.Cryptography.Native.Android.so (offset 0xe7000) (JNI_OnLoad+31302) (BuildId: 7d9e4013a9dd99810070587ab42956703fef69f9)

Co-authored-by: Jonathan Peppers <[email protected]>
Co-authored-by: Šimon Rozsíval <[email protected]>
grendello added a commit that referenced this pull request Feb 21, 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:       #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.
grendello added a commit that referenced this pull request Jul 13, 2023
)

Context: 929e701
Context: ce2bc68
Context: dotnet#7473
Context: dotnet#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 dotnet#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 dotnet#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   :       dotnet#4 pc 00000000002be0bc  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       dotnet#5 pc 00000000002bf050  /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
	F DEBUG   :       dotnet#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   :       dotnet#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
grendello added a commit that referenced this pull request Jul 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants