Crash on startup for default MAUI Blazor app on Android release mode

[SteveSandersonMS]

Description

A default MAUI Blazor application built in Release mode crashes immediately on startup in Android. I've checked this in the Android emulator, and others have reported it for physical devices. The problem doesn't occur in debug builds.

Using adb logcat I see:

01-21 15:58:46.644  7783  7837 W nyname.mauiapp: Attempt to remove index outside index area (9 vs 10-10)
01-21 15:58:46.644  7783  7837 W nyname.mauiapp: JNI WARNING: DeleteLocalRef(0x91) failed to find entry
01-21 15:58:46.701  7867  7867 F crashpad: dlopen: dlopen failed: library "libandroidicu.so" not found: needed by /system/lib64/libharfbuzz_ng.so in namespace (default)
01-21 15:58:46.702  7783  7837 F libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4 in tid 7837 (ThreadPoolForeg), pid 7783 (nyname.mauiapp2)
01-21 15:58:46.770  7870  7870 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
01-21 15:58:46.771   284   284 I tombstoned: received crash request for pid 7837
01-21 15:58:46.772  7870  7870 I crash_dump64: performing dump of process 7783 (target tid = 7837)
01-21 15:58:46.777  7870  7870 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-21 15:58:46.777  7870  7870 F DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64_arm64:11/RSR1.201211.001/7027799:user/release-keys'
01-21 15:58:46.777  7870  7870 F DEBUG   : Revision: '0'
01-21 15:58:46.777  7870  7870 F DEBUG   : ABI: 'x86_64'
01-21 15:58:46.778  7870  7870 F DEBUG   : Timestamp: 2022-01-21 15:58:46+0000
01-21 15:58:46.778  7870  7870 F DEBUG   : pid: 7783, tid: 7837, name: ThreadPoolForeg  >>> com.companyname.mauiapp2 <<<
01-21 15:58:46.778  7870  7870 F DEBUG   : uid: 10155
01-21 15:58:46.778  7870  7870 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
01-21 15:58:46.778  7870  7870 F DEBUG   : Cause: null pointer dereference
01-21 15:58:46.778  7870  7870 F DEBUG   :     rax 000070fc876bf820  rbx 000070fc876bfdc0  rcx 0000000000000000  rdx 000070fc876bf820
01-21 15:58:46.778  7870  7870 F DEBUG   :     r8  fffffffffffffdd0  r9  000070fc876bfe40  r10 0000000000000000  r11 000070fc8c34bb30
01-21 15:58:46.779  7870  7870 F DEBUG   :     r12 000070fc876bfbe0  r13 000070fce442b550  r14 000070fe54b03098  r15 0000000000000000
01-21 15:58:46.779  7870  7870 F DEBUG   :     rdi 000070fc876bfdc0  rsi 0000000000000000
01-21 15:58:46.779  7870  7870 F DEBUG   :     rbp 0000000000000000  rsp 000070fc876bfba0  rip 000070fce49048fc
01-21 15:58:46.838  7870  7870 F DEBUG   : backtrace:
01-21 15:58:46.838  7870  7870 F DEBUG   :       #00 pc 000000000065d8fc  /apex/com.android.art/lib64/libart.so (void art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+156) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
01-21 15:58:46.838  7870  7870 F DEBUG   :       #01 pc 000000000069b25d  /apex/com.android.art/lib64/libart.so (art::Thread::GetCurrentMethod(unsigned int*, bool, bool) const+157) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
01-21 15:58:46.838  7870  7870 F DEBUG   :       #02 pc 0000000000430fed  /apex/com.android.art/lib64/libart.so (art::JNI<false>::FindClass(_JNIEnv*, char const*)+765) (BuildId: 7fbaf2a1a3317bd634b00eb90e32291e)
01-21 15:58:46.838  7870  7870 F DEBUG   :       #03 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)
01-21 15:58:46.838  7870  7870 F DEBUG   :       #04 pc 00000000000128ac  <anonymous:41640000>
01-21 15:58:47.095   284   284 E tombstoned: Tombstone written to: /data/tombstones/tombstone_03

Is there someone working MAUI core that could help us make sense of this? I'm on the Blazor team and am not sure how we can proceed with understanding the error and figuring out whether it's something in BlazorWebView or is due to an issue in MAUI itself. If the fault is (as logged above) library "libandroidicu.so" not found then it seems like something controlled by MAUI core rather than BlazorWebView.

If it is a fault in BlazorWebView, can you give any suggestions on how we'd find out even which part of our code is running to trigger this?

Note: this probably duplicates #3816 and #2246 and #3060, but I'm filing this new issue to try to consolidate what we know in one place.

Steps to Reproduce

1. Create a new MAUI Blazor application
2. Change build configuration to Release
3. Change target device to Android emulator (I'm using Pixel 5 - API 30)
4. Ctrl+F5 (or just F5) to launch

Version with bug

Preview 12 (current)

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

API 30, probably others too

Did you find any workaround?

No. However this issue seems similar to #2246 and #3060, which people said they could work around by adding <AndroidLinkMode>None</AndroidLinkMode>.

However that doesn't seem to work when I try it (it leads to a build error), and in any case, other people were reporting the logged error as java.lang.ClassNotFoundException: Didn't find class "android.view.View$OnUnhandledKeyEventListener" which seems to be a long-running Xamarin issue and is not the same as what I saw in the adb logcat output. So it's possible those other issues are unrelated.

Relevant log output

No response

[SteveSandersonMS]

@Eilon Since this has been triaged as area/blazor it's just come back to us. Can you recommend someone who works on the core Android support who might be able to give us some help with tracing into the internals here?

[Eilon]

@jonathanpeppers is who I'd ping.

But I updated the area on this to publishing because I think it's a bit closer to that area. The people applying the labels don't necessarily look at the history of an issue so that's probably why it would otherwise keep ending up tagged as Blazor.

[SteveSandersonMS]

Thanks! It looks like @jonathanpeppers is already investigating at #2246 (comment), so I'll wait for his investigation there.

[jonathanpeppers]

This appears to be a linker issue Java.IO.InputStreamHandler.GetReadHandler() is removed -- I've first fixed this case where we are actually losing the managed exception, and getting a crash instead:

dotnet/android#6672

Will look into actually fixing the problem next.