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

オープン
  • 何か問題がありますか？
#5,703 コメント 0 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
csharp
領域
backend, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).
主要言語
C#
スター
26.8k
フォーク
970
平均マージ
17時間 39分
マージ済み PR（30日）
132

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Devolutions/UniGetUI のほかの issue

Devolutions/UniGetUI の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。