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

Some App tests leave closed windows alive after GC

Abierto
  • ¿Algo no está bien?
#666 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@SeoJCalive ya está trabajando en esto.

Desde el 27/10/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Follow-up from #540 / #636.

While measuring #540 (full App run on Linux, f80ecb74, before #636, with my measuring hooks: a GC every 30 s and a count of live windows), windows that tests had already closed were still alive after a GC:

  • Up to 44 closed windows were still alive after a GC; at 4620 s, 44 of the 49 live windows had already been closed. Windows alive after a GC, open ones included, peaked at 62.
  • The working set rose from 345 MB to about 760 MB in the first ~21 min, then stayed between 742 and 929 MB until the end.
  • Run on their own 40 times, the main window and the close dialog were released after GC, so it isn't those two by themselves. I don't know yet which tests leave windows behind.

Since #636 this no longer costs much time, but the windows still hold memory, and it is worth knowing whether the app itself can keep a closed window alive.

What I'd do:

  1. Find the tests: after each test, run a GC and record which closed windows are still alive, over a full App run.
  2. Find what holds them: for those tests, check what keeps the window reachable (an event subscription, a service or view model, a test helper).
  3. Report before fixing: post the results here first, including whether the same thing can happen in the app or only in the tests, and then decide the fix.
Lenguaje dominante
C#
Estrellas
3.6k
Forks
192
Merge medio
7 h 42 min
PR fusionados (30 d)
272

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 KnifeLemon/Filee

Todos los issues de KnifeLemon/Filee

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.