Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Bug]: Desktop app becomes extremely slow (suspected memory leak) after repeated Excel edits + browser screenshots across concurrent sessions

Offen
  • Stimmt etwas nicht?
#552 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
15/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Aktiv
Tech-Stack
macos, python
Bereich
desktop-dev, performance

Rechercherichtung

The payload names the bundled xlsx skill's scripts/recalc.py, scripts/office/unpack.py and pack.py, plus the screenshot-to-workbook embedding path, but no heap profile or failing test. Start by reproducing the loop of about ten edit and screenshot rounds in one session and capturing a heap snapshot to see what is retained. Done means the retention point is identified and a fix or follow-up issue is filed.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

desktop
Product or interface

Desktop app

Version

Desktop app 3.1.6 (build 3.1.6.195)

Platform

macOS

OS version and architecture

macOS 27.0.1, arm64 (Apple Silicon)

Issue area

Agent stuck / slow / repeated loop

Desktop log upload ID (optional)

Not available at the time of filing. Happy to upload a diagnostic bundle / logs if you tell me which ones you need.

Steps to reproduce
  1. Open the Desktop app and run two sessions in parallel, both working on spreadsheet files at the same time.
  2. In each session, repeat the following loop roughly 10 times:
    1. Send a normal instruction that triggers a search (web search / fetch).
    2. Ask the agent to fill data into an .xlsx workbook (Excel edit).
    3. Take a browser screenshot and paste / embed the image into the same workbook.
    4. Send another instruction, then go back to step 1.
  3. Tools involved in the loop:
    • Excel editing: the bundled xlsx skill (pandas + openpyxl, plus scripts/recalc.py and scripts/office/unpack.py / pack.py for the workbook ZIP package).
    • Browser screenshot, including embedding the screenshot image into the workbook.
    • ZIP pack / unpack of the workbook package.
Expected and actual behavior

Expected: memory usage per session stays roughly flat over repeated iterations, and each round of the loop completes at a consistent speed.

Actual: after roughly 10 rounds in each session, the whole app becomes extremely slow. Every action (sending a command, running a tool call, editing the workbook) is visibly delayed, and the slowdown does not recover on its own. It feels like a memory leak, but I have not yet captured a heap profile, so I cannot confirm where the retention happens.

Observations so far:

  • The degradation is cumulative and roughly proportional to the number of edit + screenshot rounds, not to the size of the workbook or the number of rows written.
  • It affects both concurrent sessions at the same time, which makes it look app-wide / process-wide rather than limited to one session.
  • No error, crash, or warning is surfaced. The app just gets slower, with no obvious signal about which tool call is responsible.
  • Starting fresh sessions (or restarting the app) restores normal speed, which suggests something is retained for the lifetime of the running process / session.
Redacted error summary

No error output. This is a performance / suspected-leak report, so there is no stack trace to share. I can capture a heap snapshot or the diagnostic bundle if that is the right next step — please let me know which artifact you need.

Suspected areas (guesses, not confirmed)

I may be wrong about the component, so please treat this section as hypotheses:

  1. Excel path — the bundled xlsx skill. Each edit spawns Python (pandas / openpyxl), scripts/recalc.py launches headless LibreOffice (soffice), and the pack/unpack step extracts the workbook package to a temp directory. Possible causes: lingering soffice child processes or LibreOffice profile state accumulating across recalcs, extracted temp directories / cached workbook copies never being cleaned up, or the workbook package being held in memory by the runtime.
  2. Screenshot path — screenshots are returned as base64 image payloads inside tool results and are additionally embedded into the workbook as PNGs. Possible causes: screenshot payloads retained in the conversation / tool-result history of each session, or the asset / session-asset store accumulating every screenshot and embedded image without eviction.
  3. Combination — with two sessions running the same loop concurrently, whichever of the above retains data is multiplied by two.
What would help to triage
  • Which diagnostic artifact you want from the Desktop app (Settings → General → Upload logs, or a heap snapshot) and where it should be sent.
  • Whether the Desktop app exposes a memory-usage counter, or an action to clear session data / cached assets, that I should try between iterations to confirm the retention point.
  • Whether repeated LibreOffice recalculation (soffice) inside one long-running session is expected to stay cheap, or whether it is known to accumulate.
Before submitting
  • I have searched existing issues.
  • I have included my version and removed sensitive information.
Vorherrschende Sprache
TypeScript
Sterne
2.1k
Forks
271
Ø Merge
9 Std. 55 Min.
Gemergte PRs (30 T.)
52

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus MiniMax-AI/minimax-code

Alle Issues in MiniMax-AI/minimax-code

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.