[msbuild] Preserve overriden values and only override on VS2017+ #1

kzu · 2017-04-03T19:21:10Z

Since we now have the Sdk imports in VS2013/15 too, we need to also
detect VsInstallRoot before overriding the framework paths.

Also, if alternative values have already been provided, we should
not override them (i.e. CI where the location is != than the VS
install location, etc.)

(CP from xamarin/XamarinVS@a2a4958)

Related to dotnet#541

Since we now have the Sdk imports in VS2013/15 too, we need to also detect VsInstallRoot before overriding the framework paths. Also, if alternative values have already been provided, we should not override them (i.e. CI where the location is != than the VS install location, etc.) (CP from xamarin/XamarinVS@a2a4958)

Fixes: dotnet#1296 Xamarin.Android attempts to expose the Java-based Android API as a ".NET feeling" API. This takes many forms, such as prefixing interface names with `I`, mapping `get` and `set` methods to properties, mapping listener interfaces to events, and PascalCasing method names. This also affects Java package names and C# namespaces. When creating the `.apk` file, we philosophically need to go the opposite direction: PascalCased members need to be mapped to "something appropriate" within Java. For example, many Android Resource ids *must* be all lowercase, and Android doesn't support package names starting with an uppercase letter in all circumstances. At one point, we tried mapping C# PascalCased namespaces to camelCased namespaces, so e.g. `MyExampleNamespace` became the `myExampleNamesapce` Java package within Java Callable Wrappers. This turned out to be a Terrible Mistake, particularly on case-sensitive filesystems, as if casing was *inconsistent* (`MyExampleNamespace` vs `MyExamplenamespace`), files might not be packaged. By Mono for Android 1.0, we settled on just lowercasing the namespace name to produce Java package names within Android Callable Wrappers. This was not without it's own problems; in particular, the assembly name wasn't involved, so if the "same" type (namespace + type) were present in two different assemblies and we needed to generate Android Callable Wrappers, they'd "collide," the build would fail, and we'd have some unhappy customers. This was later addressed in Xamarin.Android 5.1 by changing the Java package name generation algorithm to be an MD5SUM of the assembly name and namespace name, thus allowing types to have assembly identity. (This was not without its own problems.) Then it gets slightly more complicated: Android allows type names to appear in various locations, such as in layout View XML. These don't allow "just" using the type name; the package name is required for types outside the `android.widget` Java package. Initially, we did nothing, so developers had to directly use the Android Callable Wrapper names: <myexamplenamespace.MyCustomCSharpView android:id="@+id/yay_csharp" .../> <fragment android:name="myexamplenamespace.MyCustomCSharpFragment" ... /> With the change in Xamarin.Android 5.1, *this couldn't work*; those types didn't exist anymore. To square this circle, we processed the resource files to "fixup" identifiers and replace them with the actual Android Callable Wrapper names. We'd replace any/all of: MyExampleNamespace.MyCustomCSharpView // Full name MyExampleNamespace.MyCustomCSharpView, MyAssembly // Partial assembly-qualified name MyExampleNamespace.MyCustomCSharpView, MyAssembly, Version=... // Full assembly qualified name myexamplenamespace.MyCustomCSharpView // compatibility name with the appropriate md5'd Android Callable Wrapper name. Brilliant as this was, there was a problem: [Bug #61073][61073]. If the assembly had a wildcard in the assembly version: [61073]: https://bugzilla.xamarin.com/show_bug.cgi?id=61073 [assembly: AssemblyVersion ("1.0.0.*")] then the "Full assembly qualified name" value would change on *every build*, which had numerious unintended knock-on effects. This was fixed in commit e5b1c92, which worked largely by just killing the Full assembly qualified name version entirely. Xamarin.Android doesn't support embedding two different versions of the same assembly, so this was considered to be fine. ...except for one compatibility case: `<fragment/>`s can contain ~arbitrary strings, and we support replacing the entire Full assembly qualified name within them: <fragment android:name="MyExampleNamespace.MyCustomCSharpFragment, MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" ... /> However, in a post e5b1c92 world, the above now fails to load on the device, because it's *not* being appropriately fixed up! FATAL EXCEPTION: main Process: Mono.Samples.HelloTests, PID: 22977 java.lang.RuntimeException: Unable to start activity ComponentInfo{Mono.Samples.HelloTests/mono.samples.HelloApp}: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment ... Caused by: android.view.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class fragment Caused by: android.view.InflateException: Binary XML file line #1: Error inflating class fragment Caused by: android.app.Fragment$InstantiationException: Unable to instantiate fragment Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null: make sure class name exists, is public, and has an empty constructor that is public ... Caused by: java.lang.ClassNotFoundException: Didn't find class "Mono.Samples.Hello.MyFragment, Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" on path: DexPathList[[zip file "/data/app/Mono.Samples.HelloTests-1/base.apk"],nativeLibraryDirectories=[/data/app/Mono.Samples.HelloTests-1/lib/arm64, /system/fake-libs64, /data/app/Mono.Samples.HelloTests-1/base.apk!/lib/arm64-v8a, /system/lib64, /vendor/lib64]] ... The problem is that what Android "sees" *should* be <fragment android:name="md5whatever.MyCustomCSharpFragment" ... /> where `md5whatever.MyCustomCSharpFragment` *is* a valid Java type that Android is able to load successfully, but because of e5b1c92 this replacement was removed. The fix: simplify the Full assembly-qualified name case to an already supported example. If the `//fragment/@android:name` value contains a `,`, assume it's an assembly qualified name and compute the Full name from it, by stripping off the comma and everything after it, then use the Full name to lookup the correct Android Callable Wrapper type.

@jonpryor

Xamarin.Android uses the [ILRepack task][0] to repack/merge the `Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is performed after the `Xamarin.Android.Build.Tasks.csproj` project's `Build` target completes. The step takes the project's output assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other dependencies, then merges them into one, *replacing* the original output assembly. The majority of time it works flawlessly, however when building the `monodroid` repo we observe a Mono runtime crash, similar-but-not- identical to [mono issue 9613][m9613]. Not all details are understood, but the high level overview of the issue is as follows: Mono runtime uses the **mmap**(2) system call on Unix to map the on-disk image of the assembly into memory. The `mmapp`ed area is used whenever the same assembly is loaded (e.g. `Assembly.LoadFrom()`) into the application to save time and memory. The memory is mapped as private which means that anything written to the mapped area by the Mono process is effectively discarded, that is not reflected in the file on disk. The protection, however, doesn't work in the other direction: when an external process (or even the same Mono process!) writes to the file that was `mmapp`ed. Unfortunately, the OS kernel behavior in such instance is left undefined by the POSIX standard: the kernel can choose to reflect the on-disk change in the mapping or ignore it. On macOS the write is ignored; on Linux, the write leads either to the `SIGBUS` signal being sent to the process or corruption to the `mmap`ped memory area (details of how this happens are, as of yet, unknown; it's just a theory at this point). The problem occurs in our case when the `<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping of that assembly, eventually crashing: ## native crash #0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 #1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719 #2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742 dotnet#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938 dotnet#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441 dotnet#5 <signal handler called> dotnet#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199 dotnet#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663 dotnet#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242 dotnet#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755 dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638 dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206 dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272 ... ## managed stacktrace at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0 at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539 at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571 at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0 ... The crash occurs in frame 7, because the `r` parameter (an instance of the `MonoAssembly` structure) contains pointers that used to point to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed area, but now point to garbage data. One of those corrupted pointers is the ASCII assembly name - which is used by the function in frame 7. The crash this commit fixes occurs in a very specific scenario: when building the `OpenTK.csproj` project *directly* (e.g. `msbuild OpenTK.csproj`), which causes the `Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in the `<UsingTask/>` MSBuild statement, but at the same time `OpenTK.csproj` has a `@(ProjectReference)` to `Xamarin.Android.Build.Tasks.csproj`, which caused the `<ILRepacker/>` task to run unconditionally, attempting to repack the assemblies again and leading to the crash described above. The fix, courtesy of @jonpryor, is to make the `ILRepacker` target not run every time but only whenever the assembly has to be re-packed because it has just been rebuilt. This also improves rebuild times. [0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task [m9613]: mono/mono#9613

…e fixed up. (dotnet#1720) Context: dotnet#1711 When using a custom view within a layout file we replace the `namespace.classname` with an `md5hash.classname`. We do this by using the `acwmap.txt` file to map known types onto the `md5` hashed ones. This is done in a case sensitive manner. We also only support identically-cased and lower-cased namespace/package names: ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView Given that a user is able to type these manually it is possible that typo's will occur. If for example a user types Classlibrary1.CustomView this will NOT be fixed up, due to the lowercase `l` in `library`. Instead the user will see the following error at runtime. FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView" If the control is used in a number of places this runtime error does nothing to help track down the problem. Improve this scenario by detecting these issues and emitting an XA1002 build error. This will not only inform the user about the problem but also provide a link to the file causing the problem.

@jonpryor

Xamarin.Android uses the [ILRepack task][0] to repack/merge the `Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is performed after the `Xamarin.Android.Build.Tasks.csproj` project's `Build` target completes. The step takes the project's output assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other dependencies, then merges them into one, *replacing* the original output assembly. The majority of time it works flawlessly, however when building the `monodroid` repo we observe a Mono runtime crash, similar-but-not- identical to [mono issue 9613][m9613]. Not all details are understood, but the high level overview of the issue is as follows: Mono runtime uses the **mmap**(2) system call on Unix to map the on-disk image of the assembly into memory. The `mmapp`ed area is used whenever the same assembly is loaded (e.g. `Assembly.LoadFrom()`) into the application to save time and memory. The memory is mapped as private which means that anything written to the mapped area by the Mono process is effectively discarded, that is not reflected in the file on disk. The protection, however, doesn't work in the other direction: when an external process (or even the same Mono process!) writes to the file that was `mmapp`ed. Unfortunately, the OS kernel behavior in such instance is left undefined by the POSIX standard: the kernel can choose to reflect the on-disk change in the mapping or ignore it. On macOS the write is ignored; on Linux, the write leads either to the `SIGBUS` signal being sent to the process or corruption to the `mmap`ped memory area (details of how this happens are, as of yet, unknown; it's just a theory at this point). The problem occurs in our case when the `<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping of that assembly, eventually crashing: ## native crash #0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30 #1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719 #2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742 dotnet#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938 dotnet#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441 dotnet#5 <signal handler called> dotnet#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199 dotnet#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663 dotnet#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242 dotnet#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755 dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638 dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206 dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272 ... ## managed stacktrace at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0 at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539 at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571 at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0 ... The crash occurs in frame 7, because the `r` parameter (an instance of the `MonoAssembly` structure) contains pointers that used to point to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed area, but now point to garbage data. One of those corrupted pointers is the ASCII assembly name - which is used by the function in frame 7. The crash this commit fixes occurs in a very specific scenario: when building the `OpenTK.csproj` project *directly* (e.g. `msbuild OpenTK.csproj`), which causes the `Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in the `<UsingTask/>` MSBuild statement, but at the same time `OpenTK.csproj` has a `@(ProjectReference)` to `Xamarin.Android.Build.Tasks.csproj`, which caused the `<ILRepacker/>` task to run unconditionally, attempting to repack the assemblies again and leading to the crash described above. The fix, courtesy of @jonpryor, is to make the `ILRepacker` target not run every time but only whenever the assembly has to be re-packed because it has just been rebuilt. This also improves rebuild times. [0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task [m9613]: mono/mono#9613

…e fixed up. (dotnet#1720) Context: dotnet#1711 When using a custom view within a layout file we replace the `namespace.classname` with an `md5hash.classname`. We do this by using the `acwmap.txt` file to map known types onto the `md5` hashed ones. This is done in a case sensitive manner. We also only support identically-cased and lower-cased namespace/package names: ClassLibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView classlibrary1.CustomView=md5d6f7135293df7527c983d45d07471c5e.CustomTextView Given that a user is able to type these manually it is possible that typo's will occur. If for example a user types Classlibrary1.CustomView this will NOT be fixed up, due to the lowercase `l` in `library`. Instead the user will see the following error at runtime. FATAL UNHANDLED EXCEPTION: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Android.Views.InflateException: Binary XML file line #1: Error inflating class Classlibrary1.CustomTextView ---> Java.Lang.ClassNotFoundException: Didn't find class "Classlibrary1.CustomTextView" If the control is used in a number of places this runtime error does nothing to help track down the problem. Improve this scenario by detecting these issues and emitting an XA1002 build error. This will not only inform the user about the problem but also provide a link to the file causing the problem.

…2199) Fixes: dotnet#2193 I have been able to reproduce a #deletebinobj bug with the following steps: 1. `File | New Project | Android App (Xamarin) | Tabbed App`, set `Minimum Android Version` to `Android 5.0 (Lollipop)` 2. Build 3. Add a new `TextView` to `Resources\layout\activity_main.axml`, with an id of `textView1` 4. Build and Deploy Get a crash at runtime: Android.Views.InflateException: Binary XML file line #1: Error inflating class android.support.design.widget.BottomNavigationView occurred A `Rebuild` fixes the problem, and the app starts correctly again. After comparing `obj` directories from before and after, I noticed `obj\Debug\android\src\android\support\compat\R.java` was missing the field for `R.id.textView1`! public static int textView1=0x7f080091; This doesn't match the error message we are getting here at all... But this file is updated by the `_GenerateJavaDesignerForComponent` MSBuild target. Further research showed that this target was getting skipped at step no. 4 above, because it was found to be up to date according to its inputs and outputs. To verify this was the case, I could delete `obj\Debug\Component.R.cs.flag` which would also resolve the runtime exception (instead of a full `Rebuild`). First, I created a new test: - `CustomViewAddResourceId` builds a project with `<android.support.design.widget.BottomNavigationView />` - Adds a `textView1` layout, builds again - Verifies that `obj\Debug\android\src\android\support\compat\R.java` contains `textView1` To fix the problem, I did the following: - Added `$(_AndroidResgenFlagFile)` as an input to `_GenerateJavaDesignerForComponent`, so it will run again when `_UpdateAndroidResgen` runs - Removed `AndroidComponentResgenFlagFile="$(_AndroidComponentResgenFlagFile)"` from the call to the `<Aapt />` MSBuild task, so it will re-run `aapt` and generate `R.java`. However, things were breaking when `$(AndroidUseAapt2)` was enabled. For `aapt2` support I had to: - Remove `AndroidComponentResgenFlagFile` from the `<Aapt2Link />` call - Set an extra property that the other `<Aapt2Link />` calls are already doing: `CompiledResourceFlatArchive="$(IntermediateOutputPath)\compiled.flata"`

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 : dotnet#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.

Currently when running the `Mono.Android-Test` app we get the following error: Java.Lang.RuntimeException: Binary XML file line #1: You must supply a layout_width attribute. This is because `ScrollView` now needs to have the properties `//@android:layout_width` and `//@android:layout_height`. Once we provide those, we then get: Scrollview can host only one direct child We then need to add a `LinearLayout` to the `ScrollView` so that it removes that error as well.

…t#2735) Fixes: dotnet#2684 Context: https://www.guardsquare.com/en/products/proguard/manual/usage#keepoptionmodifiers Context: https://www.guardsquare.com/en/products/proguard/manual/examples Using R8 on a pre-Android 8.0 device was crashing with: Unhandled Exception: Java.Lang.LinkageError: no non-static method "Landroid/runtime/UncaughtExceptionHandler;.<init>()V" at Java.Interop.JniEnvironment+InstanceMethods.GetMethodID (Java.Interop.JniObjectReference type, System.String name, System.String signature) [0x0005b] in <7d7bcc9ee9cc460db8abcdb9a9622733>:0 at Java.Interop.JniType.GetConstructor (System.String signature) [0x0000c] in <7d7bcc9ee9cc460db8abcdb9a9622733>:0 at Java.Interop.JniPeerMembers+JniInstanceMethods.GetConstructor (System.String signature) [0x00035] in <7d7bcc9ee9cc460db8abcdb9a9622733>:0 at Java.Interop.JniPeerMembers+JniInstanceMethods.FinishCreateInstance (System.String constructorSignature, Java.Interop.IJavaPeerable self, Java.Interop.JniArgumentValue* parameters) [0x00036] in <7d7bcc9ee9cc460db8abcdb9a9622733>:0 at Java.Lang.Object..ctor () [0x00054] in <d77389624c8c4948a12589c4bd4500eb>:0 at Android.Runtime.UncaughtExceptionHandler..ctor (Java.Lang.Thread+IUncaughtExceptionHandler defaultHandler) [0x00000] in <d77389624c8c4948a12589c4bd4500eb>:0 at Android.Runtime.JNIEnv.Initialize (Android.Runtime.JnienvInitializeArgs* args) [0x00202] in <d77389624c8c4948a12589c4bd4500eb>:0 --- End of managed Java.Lang.LinkageError stack trace --- java.lang.NoSuchMethodError: no non-static method "Landroid/runtime/UncaughtExceptionHandler;.<init>()V" at mono.android.Runtime.init(Native Method) at mono.MonoPackageManager.LoadApplication(:21) at mono.MonoRuntimeProvider.attachInfo(:1) at android.app.ActivityThread.installProvider(ActivityThread.java:5853) at android.app.ActivityThread.installContentProviders(ActivityThread.java:5445) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:5384) at android.app.ActivityThread.-wrap2(ActivityThread.java) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1545) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6119) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776) Looking into it, the following method was present when using ProGuard, but not R8: #1 : (in Landroid/runtime/UncaughtExceptionHandler;) name : '<init>' type : '()V' access : 0x10001 (PUBLIC CONSTRUCTOR) code - registers : 4 ins : 1 outs : 4 insns size : 22 16-bit code units catches : (none) positions : 0x0000 line=22 0x0003 line=23 0x0010 line=24 locals : 0x0000 - 0x0016 reg=3 this Landroid/runtime/UncaughtExceptionHandler; I looked at `proguard_xamarin.cfg`, and noticed something strange: -keep class android.runtime.** { <init>(***); } It seemed this rule was being ignored? All the other *working* rules were using `<init>(...);` to refer to the instance constructor. I reviewed [ProGuard's documented syntax/grammar][0]: [@annotationtype] [[!]public|final|abstract|@ ...] [!]interface|class|enum classname [extends|implements [@annotationtype] classname] [{ [@annotationtype] [[!]public|private|protected|static|volatile|transient ...] <fields> | (fieldtype fieldname); [@annotationtype] [[!]public|private|protected|static|synchronized|native|abstract|strictfp ...] <methods> | <init>(argumenttype,...) | classname(argumenttype,...) | (returntype methodname(argumenttype,...)); [@annotationtype] [[!]public|private|protected|static ... ] *; ... }] It seems `(...)` is the proper way to specify a match against any set of arguments. Looking through ProGuard's examples, I can't find any usage of `(***)`. It must *happened* to work, but is undocumented. R8 does not appear to accept the `(***)` syntax at all. Update `proguard_xamarin.cfg` so that it uses `(...)`, not `(***)`, allowing R8 to properly process `proguard_xamarin.cfg`. ~~ Other changes ~~ I expanded upon the `DexUtils` class so it can look for methods within classes. I also adjusted one test to verify this problem is solved. [0]: https://www.guardsquare.com/en/products/proguard/manual/usage#classspecification

…t#3218) Fixes: dotnet#3123 Scenario: 1. Create a Solution in which the `App.csproj` references a `MonoAndroid`-profile `Library.csproj` project. 2. `Library.csproj` contains an `Android.Views.View` subclass. 3. `Library.csproj` contains an `@(AndroidResource)` with a layout `.axml` file which uses the `View` from (2) 4. `App` project uses (2) with `Activity.SetContentView()`. 5. Build & Run the project; it works. 6. Update the `View` subclass from (2). 7. Build & run the project. Step (7) is expected to result in a successful app launch. Instead, it fails during process startup: Android.Views.InflateException: Binary XML file line #1: Binary XML file line #1: Error inflating class InflatedLibrary.CodeBehindClass occurred Commit 373c6ed added a new `_ConvertCustomView` target to handle the conversion of custom view to the md5 hash versions. While it worked *most* of the time, there was a very specific area where it was not fixing up the custom views. This problem only occurs when a library project code is updated, as with step (6). When happens next is that when the main app builds and the library resources are then re-extracted into the `$(IntermediateOutputPath)lp\XX\ji\res` directory. The `<ConvertResorucesCases/>` task is then run to fixup those `res` files with the correct casing. Then the `<GenerateJavaStubs/>` task is run, because the library project was updated. However at this point the wheels fall of the wagon because the `_ConvertCustomViews` target does NOT run. This is because it is only using the following inputs: $(_CustomViewMapFile);$(_AcwMapFile) Neither of these files are updated in this instance. `$(_AcwMapFile)` will only be updated if a class or namespace are changed. If code within a class is changed in a way which doesn't alter the class or namespace name, then nothing in the ACW map will need to be updated, so we don't update the file. The `$(_CustomViewMapFile)` is also not updated, unless resources are added or removed. So that doesn't change either. The result is the target is skipped, and we end up with a custom view which does NOT have the correct type names. This results in the above error. The fix in this case is to update the Inputs of the `_ConvertCustomView` target to have the following $(_CustomViewMapFile);$(_AcwMapFile);@(_AndroidResourceDest);@(_LibraryResourceDirectoryStamps) By including these two extra items we can make sure the target runs if either an app resource is updated or if a library project changes. A unit test has been updated to test for this particular issue.

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 : dotnet#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`.

…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 : dotnet#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 : dotnet#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.

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 : dotnet#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.

…5365) Context: dotnet#5167 The `Android.Runtime.Extensions` type is not accessed via reflection. It *is* preserved by the linker when needed, e.g.: $ illinkanalyzer -r Android.Runtime.Extensions linker-dependencies.xml.gz … --- Method:TResult Android.Runtime.Extensions::JavaCast(Android.Runtime.IJavaObject) dependencies --- Dependency #1 Method:TResult Android.Runtime.Extensions::JavaCast(Android.Runtime.IJavaObject) | MethodSpec:TResult Android.Runtime.Extensions::JavaCast<T>(Android.Runtime.IJavaObject) [1 deps] | Method:T Android.App.Activity::FindViewById(System.Int32) [1 deps] | MethodSpec:!!0 Android.App.Activity::FindViewById<Android.Widget.Button>(System.Int32) [1 deps] | Method:System.Void UnnamedProject.MainActivity::OnCreate(Android.OS.Bundle) [2 deps] | Assembly:UnnamedProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null [1 deps] | Other:Copy …

…otnet#4966) Context: dotnet#1218 (comment) The undocumented, experimental, `Hybrid` value for the `$(AndroidAotMode)` MSBuild property is not currently compatible with the armeabi-v7a target ABI. Attempting to run an app built with `$(AndroidAotMode)`=`Hybrid` in an armeabi-v7a environment results in a crash: F libc : Fatal signal 11 (SIGSEGV), code 2, fault addr 0x913a50c8 in tid 31140 (ppxamarinforms1) W : debuggerd: handling request: pid=31140 uid=10146 gid=10146 tid=31140 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** F DEBUG : Build fingerprint: 'motorola/perry_metropcs_c/perry:7.1.1/NCQS26.69-64-21/33:user/release-keys' F DEBUG : Revision: 'p3b0' F DEBUG : ABI: 'arm' F DEBUG : pid: 31140, tid: 31140, name: ppxamarinforms1 >>> com.companyname.mobileappxamarinforms1 <<< F DEBUG : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x913a50c8 F DEBUG : r0 be9384d4 r1 00000000 r2 be9385a0 r3 9320b1c0 F DEBUG : r4 00000000 r5 94167208 r6 00000000 r7 be938584 F DEBUG : r8 be938838 r9 ae040008 sl 00000000 fp be9385a0 F DEBUG : ip 913a50c8 sp be9384e4 lr 942a8420 pc 913a50c8 cpsr 000f0010 F DEBUG : F DEBUG : backtrace: F DEBUG : #00 pc 000250c8 [anon:libc_malloc:91380000] F DEBUG : #1 pc 0000141c <anonymous:942a7000> W ActivityManager: Activity pause timeout for ActivityRecord{7ded4d1 u0 com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity t5740} I ActivityManager: Killing 30471:com.google.android.apps.fireball/u0a145 (adj 906): empty dotnet#13 D ConnectivityService: ConnectivityService NetworkRequestInfo binderDied(NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ], android.os.BinderProxy@f4c4e10) D ActivityManager: cleanUpApplicationRecord -- 30471 E ConnectivityService: RemoteException caught trying to send a callback msg for NetworkRequest [ LISTEN id=624, [ Capabilities: INTERNET&NOT_RESTRICTED&TRUSTED&FOREGROUND] ] W : debuggerd: resuming target 31140 I BootReceiver: Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE) W ActivityManager: Force finishing activity com.companyname.mobileappxamarinforms1/crc64e53dff5578afb8f2.MainActivity I Zygote : Process 31140 exited due to signal (11) Since it is known that this configuration currently produces a crash, emit a build error for it to improve the visibility of the known issue and reduce the time users might spend searching for the cause of the crash. Other changes: Update the `HybridAOT` test to cover the new error. Correct the `IncrementalBuildTest.BuildIncrementalAot()` test so that it sets `$(AndroidSupportedAbis)`. A side effect is that the test cases that use `$(AndroidAotMode)`=`Full` now build successfully. Note that although those test cases now build successfully, the resulting app packages abort when run on device because Xamarin.Android requires JIT compilation: Unhandled Exception: System.ExecutionEngineException: Attempting to JIT compile method '(wrapper other) void Java.Interop.JavaVMInterface:PtrToStructure (intptr,object)' while running in aot-only mode. TODO: Add a build error for `$(AndroidAotMode)`=`Full`, likely by updating error XA3002.

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

…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) dotnet#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

dotnet#5811) Context: dotnet#5838 This reverts commit d13d0f9. Commit d13d0f9 inadvertently broke the [`DebuggingTest.ClassLibraryMainLauncherRuns()` unit test][0], when using a test app which: 1. Uses .NET 6, which -- because of d13d0f9 -- sets `$(AndroidEnablePreloadAssemblies)`=False by default -- with- 2. A "Debug" build (Fast Deployment enabled), with- 3. `$(AndroidLinkResources)`=False (the default; see also 9e6ce03), and- 4. launching the app, which 5. Loads an `Activity` subclass located in an assembly which is *not* the "main" App assembly then the app crashes during process startup: android.runtime.JavaProxyThrowable: System.NullReferenceException: Object reference not set to an instance of an object at MyLibrary.MainActivity.OnCreate(Bundle bundle) at Android.App.Activity.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_savedInstanceState) at com.xamarin.classlibrarymainlauncherruns.MainActivity.n_onCreate(Native Method) at com.xamarin.classlibrarymainlauncherruns.MainActivity.onCreate(MainActivity.java:29) The cause of the crash is that, because not all assemblies are loaded as part of process startup -- the whole *point* to d13d0f9 and defaulting `$(AndroidEnablePreloadAssemblies)`=False -- then [`ResourceIdManager.UpdateIdValues()`][1] isn't able to update all fields in all `Resource` types to have the values from the app's `Resource.designer.cs` file. Consequently, the values *may* be invalid, and thus the `NullReferenceException`. As an "immediate" fix is not quickly forthcoming -- though enabling `$(AndroidLinkResources)`=False *by default* is an "interesting" solution, with unknown inner dev loop performance implications -- we're reverting commit d13d0f9. Issue dotnet#5838 will track the re-enabling of `$(AndroidEnablePreloadAssemblies)`=False by default in .NET 6 apps. ~~~ Additionally, update `DebuggingTest.ClassLibraryMainLauncherRuns()` so that `Resources\layout\foo.xml` contains *valid* layout XML. It was originally: <?xml version="1.0" encoding="utf-8" ?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" /> which would crash with: Java.Lang.RuntimeException: Unable to start activity ComponentInfo{com.xamarin.classlibrarymainlauncherruns/com.xamarin.classlibrarymainlauncherruns.MainActivity}: android.view.InflateException: Binary XML file line #1 in com.xamarin.classlibrarymainlauncherruns:layout/foo: Binary XML file line #1: You must supply a layout_width attribute. ---> Android.Views.InflateException: Binary XML file line #1 in com.xamarin.classlibrarymainlauncherruns:layout/foo: Binary XML file line #1: You must supply a layout_width attribute. ---> Java.Lang.UnsupportedOperationException: Binary XML file line #1: You must supply a layout_width attribute. --- End of managed Java.Lang.UnsupportedOperationException stack trace --- java.lang.UnsupportedOperationException: Binary XML file line #1: You must supply a layout_width attribute. because the layout XML was, in fact, invalid, as it wasn't providing the required `android:layout_width` attribute. Update `foo.xml` so that it has valid layout XML: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="fill_parent" android:layout_height="wrap_content" />" This way we won't be chasing invalid XML going forward. The above `UnsupportedOperationException` *hid* the `NullReferenceException` in d13d0f9; the `NullReferenceException` wasn't visible until after the invalid XML was fixed. [0]: https://github.com/xamarin/xamarin-android/blob/bf4f4f42af26cdddb46087deed59aae8424f7942/tests/MSBuildDeviceIntegration/Tests/DebuggingTest.cs#L74-L124 [1]: https://github.com/xamarin/xamarin-android/blob/bf4f4f42af26cdddb46087deed59aae8424f7942/src/Mono.Android/Android.Runtime/ResourceIdManager.cs#L9-L31

) 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

) Fixes: dotnet#6211 Mono VM will return a valid AppDomain pointer (both in "legacy" and NET6 cases) only if the current thread is attached to some domain. It is possible that when managed code is called from an unattached Java thread, `mono_domain_get()` will return `nullptr` instead of a valid one. If we further pass `nullptr` to other Mono functions, a segfault may occur if Mono fails to validate the passed pointer. Sample code which may trigger the problem: public override void OnCreate() { AppDomain.CurrentDomain.UnhandledException += (sender, e) => { Console.WriteLine("!!! UnhandledException: " + e.ExceptionObject.GetType().FullName); }; base.OnCreate(); } protected override void OnStart() { base.OnStart(); Java.Util.Concurrent.Executors.NewSingleThreadExecutor() .Execute(new Runnable(() => { throw new Exception("Exception from Java Executor!"); })); } Possible crash caused by the above code: F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb8 in tid 19241 (pool-1-thread-1), pid 19214 (ndroidcrashtest) F DEBUG : backtrace: I hwservicemanager: getTransport: Cannot find entry [email protected]::IMapper/default in either framework or device manifest. F DEBUG : #00 pc 0011b72f /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+31) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b) F DEBUG : #1 pc 0015240d /data/app/com.companyname.androidcrashtest-sqgk-Mnu8GZM5hKPu1yWEQ==/lib/x86/libmonosgen-2.0.so (mono_domain_assembly_search+61) F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb8 in tid 19763 (pool-1-thread-1), pid 19737 (ndroidcrashtest) F DEBUG : backtrace: F DEBUG : #00 pc 0011b72f /apex/com.android.runtime/lib/bionic/libc.so (pthread_mutex_lock+31) (BuildId: 471745f0fbbcedb3db1553d5bd6fcd8b) F DEBUG : #1 pc 0026b91a /data/app/com.companyname.androidcrashtest-JQoYc3YFwZtEoSJlTqX_BA==/lib/x86/libmonosgen-2.0.so (mono_os_mutex_lock+42) To avoid the above situation, wrap the `mono_domain_get()` call into `utils.get_current_domain()` which checks the return value of `mono_domain_get()` and, if it's `nullptr`, calls `mono_get_root_domain()` and attaches the current thread to that root domain.

) 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: dotnet#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: dotnet#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.

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 : dotnet#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.

…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 : dotnet#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

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 dotnet#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

…otnet#7732) Fixes: dotnet#7335 Context: d236af5 Commit d236af5 introduced embedded assembly compression, using LZ4, which speeds up startup and reduces final package size. Assemblies are compressed at build time and, at the same time, pre- allocated buffers for the **decompressed** data are allocated in `libxamarin-app.so`. The buffers are then passed to the LZ4 APIs, all threads using the same output buffer. The assumption was that we can do fine without locking as even if overlapped decompression happens, the output data will be the same and so even if two threads do the same thing at the same time, the data will be valid at all times, so long as at least one thread completes the decompression. This assumption proved to be **largely** true, but it appears that in high concurrency cases it is possible that the data in the decompression buffer differs. This can result in app crashes: A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name) A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool >>> myapp.name <<< A/DEBUG: #1 pc 0000000000029b1c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371) A/DEBUG: #2 pc 00000000002680bc /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#3 pc 00000000002681e8 /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#4 pc 000000000008555c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) … My guess is that LZ4 either uses the output buffer as a scratchpad area when decompressing or that it initializes/modifies the buffer before writing actual data in it. With overlapped decompression, it may lead to one thread overwriting valid data previously written by another thread, so that when the latter returns the buffer it thought to have had valid data may contain certain bytes temporarily overwritten by the decompression session in the other, still running, thread. It may happen that MonoVM reads the corrupted data just when it is still invalid (before the still running decompression session actually writes the valid data), a classic race condition. To fix this, the decompression block is now protected with a startup- aware mutex. Mutex will be held only after the initial startup phase is completed, so there should not be much loss of startup performance.

…otnet#7817) Fixes: dotnet#7335 Context: d236af5 Commit d236af5 introduced embedded assembly compression, using LZ4, which speeds up startup and reduces final package size. Assemblies are compressed at build time and, at the same time, pre- allocated buffers for the **decompressed** data are allocated in `libxamarin-app.so`. The buffers are then passed to the LZ4 APIs, all threads using the same output buffer. The assumption was that we can do fine without locking as even if overlapped decompression happens, the output data will be the same and so even if two threads do the same thing at the same time, the data will be valid at all times, so long as at least one thread completes the decompression. This assumption proved to be **largely** true, but it appears that in high concurrency cases it is possible that the data in the decompression buffer differs. This can result in app crashes: A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name) A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool >>> myapp.name <<< A/DEBUG: #1 pc 0000000000029b1c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371) A/DEBUG: #2 pc 00000000002680bc /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#3 pc 00000000002681e8 /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#4 pc 000000000008555c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) … My guess is that LZ4 either uses the output buffer as a scratchpad area when decompressing or that it initializes/modifies the buffer before writing actual data in it. With overlapped decompression, it may lead to one thread overwriting valid data previously written by another thread, so that when the latter returns the buffer it thought to have had valid data may contain certain bytes temporarily overwritten by the decompression session in the other, still running, thread. It may happen that MonoVM reads the corrupted data just when it is still invalid (before the still running decompression session actually writes the valid data), a classic race condition. To fix this, the decompression block is now protected with a startup- aware mutex. Mutex will be held only after the initial startup phase is completed, so there should not be much loss of startup performance.

…otnet#7732) Fixes: dotnet#7335 Context: d236af5 Commit d236af5 introduced embedded assembly compression, using LZ4, which speeds up startup and reduces final package size. Assemblies are compressed at build time and, at the same time, pre- allocated buffers for the **decompressed** data are allocated in `libxamarin-app.so`. The buffers are then passed to the LZ4 APIs, all threads using the same output buffer. The assumption was that we can do fine without locking as even if overlapped decompression happens, the output data will be the same and so even if two threads do the same thing at the same time, the data will be valid at all times, so long as at least one thread completes the decompression. This assumption proved to be **largely** true, but it appears that in high concurrency cases it is possible that the data in the decompression buffer differs. This can result in app crashes: A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name) A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool >>> myapp.name <<< A/DEBUG: #1 pc 0000000000029b1c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371) A/DEBUG: #2 pc 00000000002680bc /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#3 pc 00000000002681e8 /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: dotnet#4 pc 000000000008555c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) … My guess is that LZ4 either uses the output buffer as a scratchpad area when decompressing or that it initializes/modifies the buffer before writing actual data in it. With overlapped decompression, it may lead to one thread overwriting valid data previously written by another thread, so that when the latter returns the buffer it thought to have had valid data may contain certain bytes temporarily overwritten by the decompression session in the other, still running, thread. It may happen that MonoVM reads the corrupted data just when it is still invalid (before the still running decompression session actually writes the valid data), a classic race condition. To fix this, the decompression block is now protected with a startup- aware mutex. Mutex will be held only after the initial startup phase is completed, so there should not be much loss of startup performance.

) 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 : dotnet#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

kzu force-pushed the jonp-vsix branch from ba4f478 to 00334a0 Compare April 3, 2017 19:23

kzu changed the title ~~[ppdb] Preserve overriden values and only override on VS2017+~~ [msbuild] Preserve overriden values and only override on VS2017+ Apr 3, 2017

jonpryor merged commit ec7c186 into jonpryor:jonp-vsix Apr 3, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[msbuild] Preserve overriden values and only override on VS2017+ #1

[msbuild] Preserve overriden values and only override on VS2017+ #1

kzu commented Apr 3, 2017 •

edited

Loading

[msbuild] Preserve overriden values and only override on VS2017+ #1

[msbuild] Preserve overriden values and only override on VS2017+ #1

Conversation

kzu commented Apr 3, 2017 • edited Loading

kzu commented Apr 3, 2017 •

edited

Loading