NativeAOT: a fatal managed exception on the main thread leaves the process alive (propagateUncaughtException has no native implementation)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 18/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- mobile-dev, operating-systems
Hướng nghiên cứu
The failing lookup is the native propagateUncaughtException declared in src/java-runtime/java/mono/android/Runtime.java; the CoreCLR counterpart is in src/native/clr/host/host-jni.cc. Start by finding where the NativeAOT runtime should provide the matching JNI symbol and why it is missing. Done would mean a fatal managed exception on the main thread terminates the process under PublishAot, confirmed by the repro in the issue.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Android framework version
net10.0-android
Affected platform version
.NET SDK 10.0.401, Microsoft.Android.Sdk 36.1.69, PublishAot=true, android-x64 on an API 35 emulator (Google APIs Play Store x86_64 image). I have not tried arm64.
Description
With NativeAOT, an unhandled managed exception on the main thread does not terminate the app. The process stays alive (adb shell ps still lists it), the UI stays wherever it was, and the crash dialog never shows. The same app built without PublishAot dies as expected.
The managed exception is logged as a FATAL EXCEPTION: main from AndroidRuntime (a JavaProxyThrowable wrapping the managed exception), then logcat shows:
E ame.ZombieRepro: No implementation found for void mono.android.Runtime.propagateUncaughtException(java.lang.Thread, java.lang.Throwable) (tried Java_mono_android_Runtime_propagateUncaughtException and Java_mono_android_Runtime_propagateUncaughtException__Ljava_lang_Thread_2Ljava_lang_Throwable_2) - is the library loaded, e.g. System.loadLibrary?
propagateUncaughtException is declared native in src/java-runtime/java/mono/android/Runtime.java. The CoreCLR host exports it (src/native/clr/host/host-jni.cc, libnet-android.map.txt). I could not find a NativeAOT counterpart by code search (not stepped through, happy to be corrected). So the JNI lookup fails and the default handler never kills the process.
The same log line is pasted in a comment in tests/MSBuildDeviceIntegration/Tests/InstallAndRunTests.cs (the NativeAOT branch of AppWithStyleableUsageRuns), so the existing tests hit it too.
Impact: a startup crash looks like a hang. Anything that detects crashes by process death never sees one. We only found this because our CI waited out its whole job timeout.
Related: #10657 / #10658 (the CoreCLR equivalent, closed) and the NativeAOT TODO list #9784 (it mentions that AppDomain.CurrentDomain.UnhandledException is skipped under NativeAOT). I found no issue covering this symptom.
Steps to Reproduce
Verified on a blank app, no third-party packages.
dotnet new android -n ZombieRepro- In
ZombieRepro.csprojadd:<PublishAot>true</PublishAot> <RuntimeIdentifier>android-x64</RuntimeIdentifier> - In
MainActivity.OnCreate, before anything else:throw new InvalidOperationException("boom"); dotnet publish -c Release -f net10.0-android(needs an NDKclangonPATHand-p:AndroidNdkDirectory=<ndk>), thenadb installthe-Signed.apkand launch it.- Wait about 15 seconds.
adb shell ps -A | grep -i zombiestill lists the process (stateS), andadb logcat -d | grep propagateUncaughtExceptionshows the "No implementation found" line. - Set
PublishAotto false, rebuild, reinstall, launch: the process is gone after the same wait and only theFATAL EXCEPTIONis logged.
Did you find any workaround?
Detect the crash from adb logcat -d -b crash (Process: <appid>, lines) instead of process death. An in-app option might be to hook AppDomain.CurrentDomain.UnhandledException and call Process.KillProcess(Process.MyPid()), but I haven't tried it, and #9784 says that event is skipped under NativeAOT.
Relevant log output
E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.companyname.ZombieRepro, PID: 4449
E AndroidRuntime: net.dot.jni.internal.JavaProxyThrowable: System.InvalidOperationException: boom
E AndroidRuntime: at ZombieRepro.MainActivity.OnCreate(Bundle savedInstanceState) + 0x27
...
E ame.ZombieRepro: No implementation found for void mono.android.Runtime.propagateUncaughtException(java.lang.Thread, java.lang.Throwable) ...
- Ngôn ngữ chính
- C#
- Star
- 2.1k
- Fork
- 581
- Merge trung bình
- 2 ngày 6 phút
- Pull request đã merge (30 ngày)
- 245
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của dotnet/android
-
Area: App+Library Build
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
EditText.getText() isn't boundĐang mởArea: Mono.Android
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
dotnet/android#9192 · 4 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
.NET 11 RC2 MAUI app fails to compile (NativeAOT) with MAUI Community ToolkitCó thể đã có người làm @simonrozsival đã nhận hôm nay. Đang mởArea: App+Library Build needs-triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
dotnet/android#13143 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 45/100
dotnet/android#13142 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
_Microsoft.Android.Resource.Designer.dll carries the build's wall-clock time as its PE TimeDateStamp, so Release builds are not reproducible (GenerateResourceDesignerAssembly passes no WriterParameters.Timestamp)Có thể đã có người làm @jonathanpeppers đã nhận hôm nay. Đang mởneeds-triage
dotnet/android#13140 · 1 bình luận · 1 reaction · 2 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của dotnet/android
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
vchelaru/FlatRedBall2#1481 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ai-chat bug trivial
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area-signalr
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
dotnet/aspnetcore#69842 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày