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

Aperta
  • Qualcosa non va?
#5,703 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).
Lingua principale
C#
Stelle
26.8k
Fork
970
Merge medio
17h 39m
PR unite (30g)
132

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Devolutions/UniGetUI

Tutte le issue di Devolutions/UniGetUI

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.