Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Flaky test] JavaObjectTest.UnreferencedInstanceIsCollected still fails after finalizer-test fix

Đang mở
#13,275 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
android, csharp
Lĩnh vực
mobile, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

flaky-tests needs-triage
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.

  1. Run the existing Mono.Android.NET-Tests on-device suite in the NativeAOT configuration used by the public package-test lane.
  2. Observe Java.InteropTests.JavaObjectTest.UnreferencedInstanceIsCollected occasionally fail with the assertion below.
  3. 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:

Ngôn ngữ chính
C#
Star
2.1k
Fork
579
Merge trung bình
1 ngày 16 giờ
Pull request đã merge (30 ngày)
258

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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/android

Tất cả issue của dotnet/android

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.