Random SIGABRT in libmonodroid on .NET 10 Release (arm64): "Cannot transition thread … with DONE_BLOCKING" on .NET TP Worker
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ó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 8/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- mobile-dev
Hướng nghiên cứu
The abort comes from xamarin::android::Helpers::abort_application in libmonodroid, triggered by a thread-state transition conflict ('Cannot transition thread … with DONE_BLOCKING' / 'ASYNC_SUSPEND_REQUESTED') on a .NET TP Worker thread during HTTPS downloads. Start by reading the runtime's thread state machine and GC suspend handling around that abort path, then compare against the possibly related #10659 and #10910. The crash is not reproducible on demand, so the first concrete step is asking the reporter for a MONO_LOG_LEVEL/GC diagnostic run rather than attempting a patch; 'done' would be a reproduced state transition plus a fix.
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 10
Description
Android framework version
net10.0-android
Affected platform version
Android 14 (HONOR CLK-LX1EEA, arm64-v8a, build HNCLK-Q:14/HONORCLK-L31/8.0.0.424C431E9R2P3)
Description
After upgrading an app from an older stack to .NET 10 (MAUI 10.0.100, F#, Fabulous 10.0.3), the Release build aborts at random while running long network downloads. Windows (net10.0-windows) is unaffected, and the previous version of the app (older .NET/MAUI/Fabulous) was stable on the same phone.
There is no managed exception or managed stack trace. The runtime calls abort() itself from xamarin::android::Helpers::abort_application, always on a .NET TP Worker thread, with one of these messages:
Abort message: 'Cannot transition thread 0x… from RUNNING with DONE_BLOCKING'
Abort message: 'Cannot transition thread 0x… from ASYNC_SUSPEND_REQUESTED with DONE_BLOCKING'
Backtrace (identical in all cases):
#00 libc.so (abort+164)
#01 libmonodroid.so (xamarin::android::Helpers::abort_application(_LogCategories, char const*, bool, std::__ndk1::source_location)+584)
Five crashes were observed, uptimes 11/152/358/543/582 s. The last but one one (543 s) is the ASYNC_SUSPEND_REQUESTED variant and happened on a clean build with AndroidEnableMarshalMethods=false, so marshal methods are not the cause. The crash is not reproducible on demand: some runs complete the download, others abort. Memory is not the cause (RSS ≈ 300–350 MB at the time of the abort). Still crashing with all runtime options disabled
dumpsys activity exit-info reports reason=5 (APP CRASH(NATIVE)), description=crash.
The ASYNC_SUSPEND_REQUESTED state suggests a race between a GC suspend and a thread returning from a blocking call, but I cannot confirm this.
What the app does
- Downloads many files over HTTPS with
HttpClient(via FsHttp) on thread-pool threads, using F#asyncandMailboxProcessor. - Runs a foreground service of type
dataSyncwhile downloading. - Registers a
ConnectivityManagercallback and polls network state. - Reports progress to a Fabulous/MAUI UI from background threads.
Settings tested
| Configuration | Result |
|---|---|
| Release, defaults (marshal methods on) | crashes (3×) |
Release, AndroidEnableMarshalMethods=false, clean build |
crashes (1×, ASYNC_SUSPEND_REQUESTED) |
[+ AndroidEnableSGenConcurrent=false, AndroidEnableProfiledAot=false, RunAOTCompilation=false, PublishTrimmed=false, RuntimeIdentifier=android-arm64] |
[fill in: N runs, result] |
| Debug build | [fill in, if tested] |
Steps to reproduce
Not reliably reproducible. Run the app on the device above and start a long-running download of many files. It aborts at an unpredictable moment, between 10 s and 10 minutes after launch. I can provide a build or a project on request, and I can run any diagnostic build or MONO_LOG setting that would help.
Environment
dotnet --info:
PS C:\Program Files (x86)\Android\android-sdk\platform-tools> dotnet --info
.NET SDK:
Version: 10.0.401
Commit: e34a38d2ae
Workload version: 10.0.401.1
MSBuild version: 18.9.11+e34a38d2a
Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.401\
.NET workloads installed:
[android]
Installation Source: SDK 10.0.400, VS 18.10.12224.181
Manifest Version: 36.1.69/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.android\36.1.69\WorkloadManifest.json
Install Type: Msi
[ios]
Installation Source: SDK 10.0.400, VS 18.10.12224.181
Manifest Version: 27.0.10722/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\27.0.10722\WorkloadManifest.json
Install Type: Msi
[maccatalyst]
Installation Source: SDK 10.0.400, VS 18.10.12224.181
Manifest Version: 27.0.10722/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maccatalyst\27.0.10722\WorkloadManifest.json
Install Type: Msi
[maui]
Installation Source: SDK 10.0.400
Manifest Version: 10.0.110/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.110\WorkloadManifest.json
Install Type: Msi
[maui-windows]
Installation Source: SDK 10.0.400, VS 18.10.12224.181
Manifest Version: 10.0.110/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.110\WorkloadManifest.json
Install Type: Msi
Configured to use workload sets when installing new manifests.
Host:
Version: 10.0.12
Architecture: x64
Commit: 95017c711e
.NET SDKs installed:
8.0.425 [C:\Program Files\dotnet\sdk]
9.0.302 [C:\Program Files\dotnet\sdk]
9.0.306 [C:\Program Files\dotnet\sdk]
9.0.309 [C:\Program Files\dotnet\sdk]
9.0.318 [C:\Program Files\dotnet\sdk]
10.0.401 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.31 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.31 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.31 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
dotnet workload list:
PS C:\Program Files (x86)\Android\android-sdk\platform-tools> dotnet workload list
Workload version: 10.0.401.1
Installed Workload Id Manifest Version Installation Source
------------------------------------------------------------------------------------
android 36.1.69/10.0.100 SDK 10.0.400, VS 18.10.12224.181
ios 27.0.10722/10.0.100 SDK 10.0.400, VS 18.10.12224.181
maccatalyst 27.0.10722/10.0.100 SDK 10.0.400, VS 18.10.12224.181
maui 10.0.110/10.0.100 SDK 10.0.400
maui-windows 10.0.110/10.0.100 SDK 10.0.400, VS 18.10.12224.181
Use `dotnet workload search` to find additional workloads to install.
Relevant packages: Microsoft.Maui.Controls 10.0.100, FSharp.Core 10.0.100, Fabulous 10.0.3, Fabulous.MauiControls 10.0.3, FsHttp 15.0.3, Microsoft.Data.SqlClient 7.0.2.
Target: net10.0-android, SupportedOSPlatformVersion 30, AndroidTargetSdkVersion 36, RID android-arm64, Release, APK.
Related reports
Possibly related to #10659 (SIGABRT in Mono assertions on .NET 10 Release, arm64) and to the marshal-methods crashes in #10910, although the latter setting did not fix this case.
Logs
Full logcat -b crash output attached ([crash.txt]) together with the exit-info dump.
--------- beginning of crash
10-04 13:30:42.667 8572 8953 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 8953 (.NET TP Worker), pid 8572 (eDownloaderMAUI)
10-04 13:30:43.970 21212 21212 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-04 13:30:43.970 21212 21212 F DEBUG : Build fingerprint: 'HONOR/CLK-LX1EEA/HNCLK-Q:14/HONORCLK-L31/8.0.0.424C431E9R2P3:user/release-keys'
10-04 13:30:43.970 21212 21212 F DEBUG : Revision: '0'
10-04 13:30:43.970 21212 21212 F DEBUG : ABI: 'arm64'
10-04 13:30:43.970 21212 21212 F DEBUG : Timestamp: 2026-10-04 13:30:42.835120156+0200
10-04 13:30:43.970 21212 21212 F DEBUG : Process uptime: 358s
10-04 13:30:43.970 21212 21212 F DEBUG : Cmdline: com.companyname.OdisTimetableDownloaderMAUI
10-04 13:30:43.970 21212 21212 F DEBUG : pid: 8572, tid: 8953, name: .NET TP Worker >>> com.companyname.OdisTimetableDownloaderMAUI <<<
10-04 13:30:43.970 21212 21212 F DEBUG : uid: 10414
10-04 13:30:43.970 21212 21212 F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
10-04 13:30:43.970 21212 21212 F DEBUG : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
10-04 13:30:43.970 21212 21212 F DEBUG : Abort message: 'Cannot transition thread 0x7532bfbc30 from RUNNING with DONE_BLOCKING'
10-04 13:30:43.971 21212 21212 F DEBUG : x0 0000000000000000 x1 00000000000022f9 x2 0000000000000006 x3 0000007532bf9af0
10-04 13:30:43.971 21212 21212 F DEBUG : x4 ff4854404c716463 x5 ff4854404c716463 x6 ff4854404c716463 x7 7f7f7f7f7f7f7f7f
10-04 13:30:43.971 21212 21212 F DEBUG : x8 00000000000000f0 x9 000000793b6b5a98 x10 0000000000000001 x11 000000793b6fd540
10-04 13:30:43.971 21212 21212 F DEBUG : x12 00000000000081aa x13 0000000000000004 x14 ffffffffffffffff x15 0000000000000000
10-04 13:30:43.971 21212 21212 F DEBUG : x16 000000793b761f38 x17 000000793b73f370 x18 0000007531d10000 x19 000000000000217c
10-04 13:30:43.971 21212 21212 F DEBUG : x20 00000000000022f9 x21 00000000ffffffff x22 b4000076db2cd540 x23 000000766d91d2a8
10-04 13:30:43.971 21212 21212 F DEBUG : x24 0000007532bf9c20 x25 0000007532bf9bb8 x26 0000007532bf9bd0 x27 0000000000204000
10-04 13:30:43.971 21212 21212 F DEBUG : x28 0000007532bfa560 x29 0000007532bf9b70
10-04 13:30:43.971 21212 21212 F DEBUG : lr 000000793b6eed94 sp 0000007532bf9ad0 pc 000000793b6eedc0 pst 0000000000000000
10-04 13:30:43.971 21212 21212 F DEBUG : 2 total frames
10-04 13:30:43.971 21212 21212 F DEBUG : backtrace:
10-04 13:30:43.971 21212 21212 F DEBUG : #00 pc 000000000005bdc0 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: d638ba9bdf4cea2cddd9bd06ae04407f)
10-04 13:30:43.971 21212 21212 F DEBUG : #01 pc 00000000000a438c /data/app/~~vLDur6GYacC1R4fWA3xIXA==/com.companyname.OdisTimetableDownloaderMAUI-YzUo479gy1jCCHv6DkxnZw==/lib/arm64/libmonodroid.so (xamarin::android::Helpers::abort_application(_LogCategories, char const*, bool, std::__ndk1::source_location)+584) (BuildId: ae7ad8820dd75996ecdee692e377f8586298ceb0)
ACTIVITY MANAGER PROCESS EXIT INFO (dumpsys activity exit-info)
Last Timestamp of Persistence Into Persistent Storage: 2026-10-04 13:23:30.635
package: com.companyname.OdisTimetableDownloaderMAUI
Historical Process Exit for uid=10414
ApplicationExitInfo #0:
timestamp=2026-10-04 13:30:44.023 pid=8572 realUid=10414 packageUid=10414 definingUid=10414 user=0
process=com.companyname.OdisTimetableDownloaderMAUI reason=5 (APP CRASH(NATIVE)) subreason=0 (UNKNOWN) status=6
importance=100 pss=227MB rss=325MB description=crash state=empty trace=null
Steps to Reproduce
The crash is intermittent and I could not reduce it to a minimal project yet, but it reproduces within minutes on my device with the full app:
- Build the app (net10.0-android, Release, RuntimeIdentifier android-arm64, signed APK) and install it on an HONOR CLK-LX1EEA running Android 14 (arm64).
- Launch the app and start a long-running download (many HTTPS file downloads on thread-pool threads, using HttpClient with F# async; a foreground service of type dataSync is running during the download; progress is reported to the UI while downloading).
- Wait. In most runs the process aborts at an unpredictable moment between 11 seconds and about 10 minutes after launch. Some runs finish the whole download without a crash.
- After the crash,
adb logcat -b crash -dshows SIGABRT on a ".NET TP Worker" thread with "Cannot transition thread … from RUNNING (or ASYNC_SUSPEND_REQUESTED) with DONE_BLOCKING", raised from xamarin::android::Helpers::abort_application.
Observed so far: 5 crashes at process uptimes of 11 s, 152 s, 358 s, 543 s and 582 s.
Still crashes with all of these set (clean build, bin/obj deleted):
- AndroidEnableMarshalMethods=false
- AndroidEnableSGenConcurrent=false
- AndroidEnableProfiledAot=false, RunAOTCompilation=false
- PublishTrimmed=false
- single RID android-arm64
Not affected: the same app on Windows (net10.0-windows), and the previous version of the app built with an older .NET/MAUI/Fabulous stack on the same phone.
I have no minimal reproduction project yet. I'm happy to test any diagnostic build or environment setting (for example MONO_LOG_LEVEL / debug.mono.log), and to attach a full adb logcat -v threadtime from a crash.
Did you find any workaround?
No response
Relevant log output
##Updating the bug report
The issue is now much more concrete:
Trigger:
System.Net.NetworkInformation.Ping.Send called from parallel thread-pool work on Android (.NET 10, Release, arm64), while other work runs. With the ping removed and everything else the same, no crashes in N runs. With the ping restored, crashes returned.
Reproduction: this makes a small test app realistic: a loop that runs Async.Parallel over two Ping.Send calls on thread-pool threads, plus some allocation or download activity in the background. If that crashes on your phone too, you have a real minimal repro, and a bug with a repro is far more likely to get attention than "random crash in a big app".
The entire source code of the app is in a private repository, but it can be made available to the maintainers of this repository upon request. See the Fabulous repository (https://github.com/fabulous-dev) for a contact email address.
- Ngôn ngữ chính
- C#
- Star
- 2.1k
- Fork
- 579
- Merge trung bình
- 2 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 222
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
-
agentic-workflows needs-triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 4/5 Hơn một tuần Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Investigate JNI reference ownership leaks and GC-bridge leak-check reliabilityCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởneeds-triage
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 50/100
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 76/100
microsoft/fluentui-blazor#5410 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Bug pulumi/pulumi
Độ 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
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
activescott/lessmsi#306 ·
-
Docs MSBuild
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
getsentry/sentry-dotnet#5691 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày