CoreCLR startup crash with `dotnet new maui -sc`

[ivanpovazan]

Android framework version

net10.0-android (Preview)

Affected platform version

.NET 10.0.100-preview.3.25167.101

Description

dotnet new maui -sc template crashes at startup with CoreCLR with:

03-25 14:32:41.634  6548  6548 D AndroidRuntime: Shutting down VM
03-25 14:32:41.635  6548  6548 E AndroidRuntime: FATAL EXCEPTION: main
03-25 14:32:41.635  6548  6548 E AndroidRuntime: Process: com.companyname.dotnetnewmauisamplecontent, PID: 6548
03-25 14:32:41.635  6548  6548 E AndroidRuntime: android.runtime.JavaProxyThrowable: [System.InvalidOperationException]: InvalidOperation_HandleIsNotInitialized
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at System.WeakReference`1.SetTarget + 0x18(Unknown Source)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at Microsoft.Maui.ApplicationModel.ActivityLifecycleContextListener.set_Activity + 0x0(Unknown Source)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at Microsoft.Maui.ApplicationModel.ActivityLifecycleContextListener.Android.App.Application.IActivityLifecycleCallbacks.OnActivityResumed + 0x0(Unknown Source)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at Android.App.Application+IActivityLifecycleCallbacksInvoker.n_OnActivityResumed_Landroid_app_Activity_ + 0xe(Unknown Source)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at crc64ba438d8f48cf7e75.ActivityLifecycleContextListener.n_onActivityResumed(Native Method)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at crc64ba438d8f48cf7e75.ActivityLifecycleContextListener.onActivityResumed(ActivityLifecycleContextListener.java:42)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.Application.dispatchActivityResumed(Application.java:431)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.Activity.dispatchActivityResumed(Activity.java:1434)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.Activity.onResume(Activity.java:1995)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at androidx.fragment.app.FragmentActivity.onResume(FragmentActivity.java:309)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1531)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.Activity.performResume(Activity.java:8422)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.ActivityThread.performResumeActivity(ActivityThread.java:4793)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:4836)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:54)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.servertransaction.ActivityTransactionItem.execute(ActivityTransactionItem.java:45)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2308)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:201)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:288)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:7898)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
03-25 14:32:41.635  6548  6548 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

This might be related to the new _AndroidUseManagedMarshalMethodsLookup feature, as passing -p:_AndroidUseManagedMarshalMethodsLookup=true with Mono reaches:

...
03-25 14:39:02.172  6939  6939 F Mono.Android: GetFunctionPointer failed: should not be reached
...

### Steps to Reproduce

1. Checkout `https://github.com/ivanpovazan/coreclr-android-perf`
2. Run: `./prepare.sh` script to download and install the latest nightly builds of dotnet SDK, dotnet/android and dotnet/maui
3. Build/run the sample with `./build.sh dotnet-new-maui-samplecontent coreclr run`
4. Observe the adb logcat

### Did you find any workaround?

No

### Relevant log output

```shell

[ivanpovazan]

/cc: @jonathanpeppers

[simonrozsival]

The problem is the use of br.s instruction when there are many UCO methods in one class:

System.InvalidProgramException: Invalid IL code in Android.Views.View:<JI>GetFunctionPointer (int): IL_0059: br.s      IL_ffffffe7
    at Java.Interop.__ManagedMarshalMethodsLookupTable__.GetFunctionPointer(Int32 classIndex, Int32 methodIndex)
    at Java.Interop.ManagedMarshalMethodsLookupTable.GetFunctionPointer(Int32 , Int32 , Int32 )
    at Java.Interop.ManagedMarshalMethodsLookupTable.GetFunctionPointer(Int32 assemblyIndex, Int32 classIndex, Int32 methodIndex, IntPtr* target)

[grendello]

Looks like we have two issues here. One is the uninitialized handle from OP (something for @jonpryor probably?) and the other is the br.s instruction, which looks like the case of switch statement being too big?

[grendello]

@simonrozsival so it looks like CIL is running out of 32-bit numbers? :) Looks like a good occasion to work on splitting the switches up by e.g. sectioning them into separate methods with separate switch statements?

[simonrozsival]

@grendello for br.s, the offset is a signed 8-bit integer, so the max offset 127 bytes. In this particular case, there were 20 cases, each case used 7 bytes, the offset was 140. I have a fix in #9969, feedback is welcome.

The CoreCLR error is unrelated and the app crashes even without marshal methods. It seems that when MAUI's crc64ba438d8f48cf7e75.ActivityLifecycleContextListener.onActivityResumed(ActivityLifecycleContextListener.java:42) is called at startup, the Activity is either null or we fail to create an instance of the managed peer. This null Activity is then passed to this setter https://github.com/dotnet/maui/blob/17bfccf22287f61ab46848e1ea44ed7f1979c3f9/src/Essentials/src/Platform/ActivityStateManager.android.cs#L192 and the subsequent call to WeakReference<Activity?>.SetTarget throws.

[simonrozsival]

... the Activity is either null or we fail to create an instance of the managed peer. This null Activity is then passed to this setter ... and the subsequent call to WeakReference<Activity?>.SetTarget throws.

The Activity is not null. The managed peer is resolved correctly. The problem seems to be with the WeakReference<T> itself. This is the exception that we see in the logs: https://github.com/dotnet/runtime/blame/main/src/libraries/System.Private.CoreLib/src/System/WeakReference.T.cs#L101-L105

@AaronRobinsonMSFT I wonder if this has something to do with the (lack of) GC bridge? Do you have an idea what could be going on?

[jonpryor]

@simonrozsival asked:

I wonder if this has something to do with the (lack of) GC bridge? Do you have an idea what could be going on?

I think that's partially involved.

I think "real" problem is that CoreCLR is still using AndroidValueManager:

android/src/Mono.Android/Android.Runtime/AndroidRuntime.cs

Lines 628 to 630 in d81cde9

	class AndroidValueManager : JniRuntime.JniValueManager {
	Dictionary<IntPtr, IdentityHashTargets> instances = new Dictionary<IntPtr, IdentityHashTargets> ();

which uses WeakReference<T>:

android/src/Mono.Android/Android.Runtime/AndroidRuntime.cs

Lines 916 to 918 in d81cde9

	class IdentityHashTargets {
	WeakReference<IJavaPeerable>? first;
	List<WeakReference<IJavaPeerable>?>? rest;

which means nothing keeps instances alive!

Until we have a GC bridge, CoreCLR needs to use something akin to NativeAotValueManager:

android/src/Microsoft.Android.Runtime.NativeAOT/Android.Runtime.NativeAOT/NativeAotValueManager.cs

Line 19 in d81cde9

class NativeAotValueManager : JniRuntime.JniValueManager

which retains strong references to all created IJavaPeerable instances. This in turn means that nothing will be collected, but that's better than the alternative of collecting instances that are only strongly held by Java, which is the case for Activity instances.

[AaronRobinsonMSFT]

Until we have a GC bridge, CoreCLR needs to use something akin to NativeAotValueManager:

@simonrozsival @jonpryor's explaination makes sense to me and aligns with some of the magic the GC Bridge mechanism adds to the GC.