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

Đang mở
  • Có gì không ổn?
#5,703 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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).
Ngôn ngữ chính
C#
Star
26.8k
Fork
970
Merge trung bình
17 giờ 39 phút
Pull request đã merge (30 ngày)
132

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Devolutions/UniGetUI

Tất cả issue của Devolutions/UniGetUI

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.