[Flaky test] JavaObjectTest.UnreferencedInstanceIsCollected still fails after finalizer-test fix
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start with tests/Mono.Android-Tests/Java.Interop-Tests/Java.Interop/JavaObjectTest.cs and inspect UnreferencedInstanceIsCollected and WaitForGC to identify which collection predicate fails. Compare the test behavior with the linked finalizer-test change and the NativeAOT task logs for builds 1637749 and 1643260. Done means the underlying cause is identified and the assertion behaves reliably in the affected configuration.
由索引模型根据 Issue 内容生成。
描述
Android framework version
net11.0-android (Preview)
Affected platform version
Public dotnet-android Azure DevOps pipeline (definition 333, dnceng-public/public), Package Tests → macOS > Tests > APKs 2, NativeAOT configuration.
Description
Java.InteropTests.JavaObjectTest.UnreferencedInstanceIsCollected intermittently fails its collection assertion even with the changes from dotnet/java-interop#1408 already present. That PR replaced GC-bridge timing waits with polling of the actual collection condition, bounded to two seconds.
The current test forces managed GC/finalizers and peer collection, then requires both the managed weak reference to be dead and PeekValue(oldHandle) to return null. The available assertion does not identify which part of that condition remained false. The underlying cause could be test timing, reference retention, or GC/peer-lifetime behavior; same-SHA retry recovery establishes nondeterminism, not correctness of the runtime.
Two exact assertion occurrences were verified from both task logs and published failed-test results:
| PR | Build | Failure | Recovery in the same build/configuration |
|---|---|---|---|
| #13164, R8 version bump | 1637749 | NativeAOT attempt 2, October 16, 2026 at 14:34 UTC | Passed attempt 3, October 20. Build source SHA: 7c26c07709b4d2d491409d83f6e5cf40744244a6. |
| #13200, startup migration cleanup | 1643260 | NativeAOT attempt 1, October 21, 2026 at 08:18 UTC | Attempt 2 crashed; this test passed attempt 3 on October 27 at the same build source SHA, 95ecc9614c2c0b8f00725eb4dd16e4ed1f74a871. This is a test recovery, not a claim that the entire latest pipeline attempt passed. |
A cross-PR survey inspected 480 native-test task logs, including earlier attempts and green builds. It recovered 385 explicit outcomes for this test across 102 builds / 83 PRs. There were two exact collection assertions, both NativeAOT, among 113 NativeAOT observations. These are sample counts including retries, not an estimated population failure probability. The requested search window was September 27–October 27, but accessible task evidence spans October 15–27; 50 deleted builds had unavailable timelines.
Scope distinction: the survey also found 31 process-crash outcomes reported against this active test. Those are not counted as this assertion failure. Sampled crash logcats show a separate JNI abort with a pending Java OutOfMemoryError, sometimes originating during earlier upload tests. This issue tracks the collection assertion only, not that distinct crash signature.
Related history:
- dotnet/java-interop#1408: prior finalizer-test stabilization, merged April 21, 2026; these failures occur after that change.
- #10358: related finalization flakiness, but specifically
Dispose_Finalized, not this assertion. - #12031: different process-global JNI reference/peer-count assertions; not an exact match.
Steps to Reproduce
No deterministic local reproduction has been established.
- Run the existing
Mono.Android.NET-Testson-device suite in the NativeAOT configuration used by the public package-test lane. - Observe
Java.InteropTests.JavaObjectTest.UnreferencedInstanceIsCollectedoccasionally fail with the assertion below. - Compare the earlier and later attempts of builds 1637749 and 1643260: the same test/configuration passes later without changing the build source SHA.
Current test source: tests/Mono.Android-Tests/Java.Interop-Tests/Java.Interop/JavaObjectTest.cs.
Did you find any workaround?
A later execution of the same configuration passed in both observed builds. This is not a guaranteed workaround: build 1643260's intervening attempt crashed with a different signature.
No test disabling or timeout increase has been validated as a fix. First distinguish which collection predicate remains false and why.
Relevant log output
failed UnreferencedInstanceIsCollected
Expected the unreferenced instance to be collected.
Expected: True
But was: False
at Java.InteropTests.JavaObjectTest.<WaitForGC>d__6.MoveNext()
at Java.InteropTests.JavaObjectTest.<UnreferencedInstanceIsCollected>d__3.MoveNext()
Exact task-log evidence:
- Build 1637749, log 1432, approximately line 1656.
- Build 1643260, log 1189, approximately line 1678.
- 主要语言
- C#
- 星标
- 2.1k
- 派生
- 579
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 253
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dotnet/android 的其他 Issue
-
Area: App+Library Build
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Area: Mono.Android
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/android#9192 · 4 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
agentic-workflows needs-triage
难度 3/5 1-2 天 新手友好度 45/100
维护者通常 1 天内回复
-
Area: CoreCLR Area: Debugger bug needs-triage
难度 5/5 一周以上 新手友好度 24/100
维护者通常 1 天内回复
-
[net11.0-android] Handler.RemoveCallbacks(Action) leaves earlier repeated posts queued, retaining managed objects and JNI references可能已有人在做 @simonrozsival 于 1 天前认领。 未关闭Area: Mono.Android needs-triage
难度 4/5 3-5 天 新手友好度 25/100
维护者通常 1 天内回复
相似的 Issue
-
bug effort:S P3
难度 2/5 1-3 小时 新手友好度 85/100
nightscout/nocturne#3093 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
维护者通常 3 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100