[BUG] Daemon memory grows into gigabytes: OperationHistory.json stores multi-MB output lines and is fully loaded and kept resident

Abierto
  • ¿Algo no está bien?
#5,703 0 comentarios 1 reacción 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
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend, performance

Línea de trabajo

Start by locating OperationHistoryRecord.MaxOutputLines and OperationHistoryStore.LoadUnlocked(); the issue identifies the oversized output line and full-store load as the memory growth path. Read the existing output-cap tests and trace how records are clamped on load and save. Done means individual lines and total record output are bounded, existing bloated history shrinks on save, and the tests work across languages.

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

Descripción

bug
Please confirm these before moving forward
  • I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
  • I have tested that this issue has not been fixed in the latest (beta or stable) release — the current main branch (e857b3f) still has OperationHistoryRecord.MaxOutputLines capping the number of output lines, not their size.
  • I have checked the FAQ section for solutions.
  • This issue is about a bug.
UniGetUI Version

2026.3.3 (Windows installer, x64)

Windows version, edition, and architecture

Windows 11, build 10.0.26200, x64

Describe your issue

The UniGetUI daemon (UniGetUI.exe --daemon, autostarted at login, only running the hourly automatic-update cycle) sits at ~3.4 GB working set / ~5.6 GB private bytes and never releases it. Task Manager can show a much smaller number after Windows trims the working set (I observed it dropping to single-digit MB at an hourly maintenance tick), but the commit charge stays — the memory is genuinely held.

Root cause chain (measured on my machine):

  1. A Chocolatey auto-update of visualstudio2026buildtools failed 25 consecutive times between 2026-10-28 and 2026-10-29 (one attempt per hourly automatic-update cycle).
  2. In each failure, the PowerShell error output echoed the whole offending payload into a single line:
    ERROR: Exception calling "DeserializeObject" with "1" argument(s): "Unterminated string..."
    producing 25 lines × ~24.5 MB each.
  3. OperationHistoryRecord.MaxOutputLines = 5000 limits the line count only, so every one of those 24.5 MB lines is persisted verbatim. OperationHistory.json grew to 615 MB: 568 records, where the 25 giant lines account for ~613 MB, and the median size of the remaining 543 records is 133 bytes.
  4. The next recorded operation makes OperationHistoryStore.LoadUnlocked() do File.ReadAllText (≈ 1.2 GB as UTF-16) plus JsonSerializer.Deserialize into a static in-memory cache that lives for the daemon's lifetime → ~3.4 GB working set / ~5.6 GB commit.
  5. Every subsequent operation re-serializes the whole store and rewrites the 615 MB file (O(store) disk write per operation).
Steps to reproduce the issue

Not strictly reproducible on demand, but the chain is: let an automatic update of a package fail in a way whose install script echoes a large payload into one output line (Chocolatey + a PowerShell DeserializeObject exception did this here), let it repeat over several automatic-update cycles, then let UniGetUI record one more operation → the daemon reads the whole store into its static cache and keeps it.

UniGetUI Log

Application logging was not enabled on this machine, so no log files are available. The evidence above comes from the on-disk state (%LOCALAPPDATA%\UniGetUI\Configuration\OperationHistory.json) and from process measurements (Get-Process working set / private bytes), both captured while reproducing the analysis.

Package Managers Logs

Not captured (logging was disabled). The offending captured output is preserved inside the history file itself; the first characters of each giant line are shown in "Describe your issue" above. I did not paste them in full (24.5 MB each).

Relevant information

Proposed fix (I have it ready as a patch and can submit a PR if maintainers agree with the direction):

  • Cap a single stored line's characters (keep both ends around a visible truncation marker) and cap the total stored characters per record (keep the tail, where results/errors live) — i.e. byte-level bounds complementing the existing line-count bound.
  • Clamp on load and on save, so stores already bloated by older versions shrink back on the next save instead of staying resident in memory and on disk.
  • The same patch makes the existing output-cap test assertions language-neutral: CoreTools.Translate returns localized markers, so Assert.Contains("omitted", ...) fails on machines running UniGetUI in a non-English language (verified on a zh-language machine, both before and after the change).
Lenguaje dominante
C#
Estrellas
26.8k
Forks
970
Merge medio
17 h 39 min
PR fusionados (30 d)
132

Preparar el entorno

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 Devolutions/UniGetUI

Todos los issues de Devolutions/UniGetUI

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.