Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#13,275 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, csharp
Área
mobile, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

Lenguaje dominante
C#
Estrellas
2.1k
Forks
579
Merge medio
1 d 16 h
PR fusionados (30 d)
253

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/android

Todos los issues de dotnet/android

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.