Android framework version
net11.0-android (Preview)
Affected platform version
.NET 11.0.100-preview.7.26381.103 / .NET MAUI 11.0.0-preview.7.26406.9
Description
A .NET MAUI BlazorWebView app segfaults on the main thread inside a JNI call made from managed code. Cause: null pointer dereference, and both the object and method registers are zero.
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000004 (read)
Cause: null pointer dereference
x21 0000000000000000 x22 0000000000000000 x25 0000000000000000
backtrace:
#00 art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(...) libart.so
#01 art::JNI<false>::CallObjectMethodA(_JNIEnv*, _jobject*, _jmethodID*, jvalue const*)+184 libart.so
#02 /memfd:doublemapper (deleted) (offset 0x3221000)
Frame #2 is the CoreCLR JIT's W^X double-mapped code region, so this is managed code calling CallObjectMethodA with a null jobject or jmethodID.
This is not #10910. That issue has a very similar tombstone — same signal, same cause, x21/x22 both zero — but is attributed to AndroidEnableMarshalMethods being on, and its workaround is to turn it off. In this app the property evaluates to False already:
$ dotnet msbuild App.Maui.csproj -p:TargetFramework=net11.0-android -getProperty:AndroidEnableMarshalMethods
{ "Properties": { "AndroidEnableMarshalMethods": "False" } }
The other differences: #10910 is .NET 10 on Mono with AOT; this is .NET 11 preview 7 on CoreCLR (hence doublemapper rather than a Mono region), and the fault address is 0x4 rather than 0x0.
Context. The crash lands 1.06 s into re-initializing the Blazor app after a WebView reload — a window with unusually heavy JNI traffic, since the whole MAUI/Blazor object graph is torn down and rebuilt while the WebView is being recreated:
15:46:21.287 new app scope created
15:46:21.414 AppScopedServiceStarter: -> PrepareFirstRender
15:46:22.475 SIGSEGV
15:46:23.036 process died
I can't attribute it to a specific call — the backtrace has only three frames and none of them name a managed method.
Possibly related. The same device produced two other native crashes in the same subsystem within three days, with a different signature: Scudo ERROR: invalid chunk state when deallocating from xamarin::android::TypeMapper::java_to_managed, on Chromium WebView thread-pool threads. Filed separately. A null JNI handle here and an invalid free there are both consistent with JNI peer/handle lifetime going wrong, but I have no evidence tying them together beyond the subsystem.
Steps to Reproduce
I don't have a minimal repro. This is a production crash: four native crashes in three days on one device, across two installed builds of the same app.
The shape of the app, since that's the best lead I can offer:
- .NET MAUI,
net11.0-android, CoreCLR, targetSdk 37, AndroidEnableMarshalMethods off.
- UI is a
BlazorWebView, with sustained JNI traffic: audio capture and playback, a foreground service, Firebase messaging, and continuous WebView JS interop.
- The crash window is a full Blazor app teardown and rebuild inside the live process — old scope disposed,
MauiWebView recreated, new scope built — triggered by the app recovering from a lost render batch.
Collect with adb shell dumpsys dropbox --print data_app_native_crash.
Did you find any workaround?
No. AndroidEnableMarshalMethods=false — the workaround for the similar-looking #10910 — is already in effect here.
Relevant log output
*** Tombstone ***
Build fingerprint: 'samsung/m3quew/m3q:16/BP4A.251205.006/S948U1UES4AZG3_OYM4AZG3:user/release-keys'
Kernel Release: '6.12.30-android16-5-pd30ff70-abogkiS948USQS4AZG3-4k'
ABI: 'arm64'
Timestamp: 2026-08-20 15:46:22.475075674-0700
Process uptime: 6776s
Cmdline: chat.actual.app
pid: 24089, tid: 24089, name: chat.actual.app >>> chat.actual.app <<<
tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
pac_enabled_keys: 000000000000000f (PR_PAC_APIAKEY, PR_PAC_APIBKEY, PR_PAC_APDAKEY, PR_PAC_APDBKEY)
esr: 0000000092000006 (Data Abort Exception 0x24)
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000004 (read)
Cause: null pointer dereference
x0 0000000002569b78 x1 0000000000027562 x2 0000000070a30bb0 x3 0000000000000000
x4 00000075b7a99290 x5 0000007ff4a5bd18 x6 0000006ed4832b20 x7 000000002000000e
x8 0000000000000002 x9 000000006f96af60 x10 000000006f7b7088 x11 000000000000001c
x12 000000006f8137a0 x13 0000007442569e78 x14 0000006edd1031e8 x15 0000000400000002
x16 00000075b802faa0 x17 00000075b76f7798 x18 0000000000000007 x19 0000007ff4a5bc80
x20 0000000000027562 x21 0000000000000000 x22 0000000000000000 x23 0000000070a30bb0
x24 00000078a4b614c0 x25 0000000000000000 x26 0000000000000002 x27 0000000070a30bb4
x28 0000000002321aa8 x29 0000007ff4a5bbf0
lr 00000075b7682180 sp 0000007ff4a5bb20 pc 00000075b76821e4 pst 0000000060001000
esr 0000000092000006
3 total frames
backtrace:
#00 pc 00000000002821e4 /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAcc...)
#01 pc 0000000000699348 /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallObjectMethodA(_JNIEnv*, _jobject*, _jmethodID*, jvalue const*)+184)
#02 pc 00000000001a65b4 /memfd:doublemapper (deleted) (offset 0x3221000)
*** Surrounding app log ***
15:46:21.287 AppUIHub [+] #4
15:46:21.414 [@trace] AppScopedServiceStarter: 6,773.762s -> PrepareFirstRender
15:46:22.320 F libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4 in tid 24089 (chat.actual.app), pid 24089
15:46:22.970 DropBoxManagerService: add tag=data_app_native_crash
15:46:22.973 ActivityManager: crash : chat.actual.app,10376
15:46:23.036 ActivityManager: Process chat.actual.app (pid 24089) has died
Android framework version
net11.0-android (Preview)
Affected platform version
.NET 11.0.100-preview.7.26381.103 / .NET MAUI 11.0.0-preview.7.26406.9
Description
A .NET MAUI BlazorWebView app segfaults on the main thread inside a JNI call made from managed code.
Cause: null pointer dereference, and both the object and method registers are zero.Frame #2 is the CoreCLR JIT's W^X double-mapped code region, so this is managed code calling
CallObjectMethodAwith a nulljobjectorjmethodID.This is not #10910. That issue has a very similar tombstone — same signal, same cause,
x21/x22both zero — but is attributed toAndroidEnableMarshalMethodsbeing on, and its workaround is to turn it off. In this app the property evaluates toFalsealready:The other differences: #10910 is .NET 10 on Mono with AOT; this is .NET 11 preview 7 on CoreCLR (hence
doublemapperrather than a Mono region), and the fault address is0x4rather than0x0.Context. The crash lands 1.06 s into re-initializing the Blazor app after a WebView reload — a window with unusually heavy JNI traffic, since the whole MAUI/Blazor object graph is torn down and rebuilt while the WebView is being recreated:
I can't attribute it to a specific call — the backtrace has only three frames and none of them name a managed method.
Possibly related. The same device produced two other native crashes in the same subsystem within three days, with a different signature:
Scudo ERROR: invalid chunk state when deallocatingfromxamarin::android::TypeMapper::java_to_managed, on Chromium WebView thread-pool threads. Filed separately. A null JNI handle here and an invalid free there are both consistent with JNI peer/handle lifetime going wrong, but I have no evidence tying them together beyond the subsystem.Steps to Reproduce
I don't have a minimal repro. This is a production crash: four native crashes in three days on one device, across two installed builds of the same app.
The shape of the app, since that's the best lead I can offer:
net11.0-android, CoreCLR, targetSdk 37,AndroidEnableMarshalMethodsoff.BlazorWebView, with sustained JNI traffic: audio capture and playback, a foreground service, Firebase messaging, and continuous WebView JS interop.MauiWebViewrecreated, new scope built — triggered by the app recovering from a lost render batch.Collect with
adb shell dumpsys dropbox --print data_app_native_crash.Did you find any workaround?
No.
AndroidEnableMarshalMethods=false— the workaround for the similar-looking #10910 — is already in effect here.Relevant log output