Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#552 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
macos, python
Área
desktop-dev, performance

Línea de trabajo

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.

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

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
2.1k
Forks
271
Merge medio
12 h 15 min
PR fusionados (30 d)
41

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 MiniMax-AI/minimax-code

Todos los issues de MiniMax-AI/minimax-code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.