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

Two concurrent unattended runs preceded a machine hang (Kernel-Power 41, no bugcheck) — original autorename diagnosis retracted, see correction

Abierto Apto para principiantes
  • ¿Algo no está bien?
#673 8 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
cli, tooling

Línea de trabajo

Empieza en adapters/tmux_base.py, donde bmad-loop crea ventanas con un nombre explícito, y revisa el manejo de opciones por ventana indicado en adapters/psmux_backend.py. Verifica el cambio con la reproducción de psmux de dos proyectos y autorename.log; se considera terminado cuando las ventanas creadas por bmad-loop ya no realizan el renombrado automático de toda la máquina, mientras que las ventanas interactivas no relacionadas permanecen sin cambios.

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

Descripción

area:adapters area:psmux bug P4
Description

bmad-loop creates its agent windows with an explicit -n <name> (adapters/tmux_base.py, new-window -t =session: -n name -c cwd), but never turns automatic-rename off on them. On the psmux backend that option defaults to on:

psmux --help
    automatic-rename    Bool Auto-rename from foreground process (default: on)

Its implementation walks the entire machine process table once per second, per pane, running a BFS over it to derive a name bmad-loop has already supplied. The cost is per-pane and machine-wide, so it is additive across projects — one psmux server per user hosts every project's sessions.

Running unattended runs in two projects at the same time put four such scanners on a process table that both runs were themselves churning. The machine hard-hung and needed a power-button reset.

I checked the v0.11.0 sources: automatic-rename is never set there either, so this is not fixed by the current release.

Why this is cross-project. bmad-loop's own isolation is correct and I verified it — sessions are tagged @bmad_project with a resolved-path digest, and prunable_sessions skips foreign tags. Nothing under .bmad-loop/ is shared. The coupling is entirely through the machine-global multiplexer server, which is invisible to per-project reasoning: project A cannot see that project B just added two more whole-machine scanners to the same server.

Steps to reproduce
  1. Two projects on one Windows machine, both bmad-loop init'd with the claude adapter, psmux backend (win32 default), no ~/.psmux.conf so option defaults apply.
  2. Start a long unattended run in project A (bmad-loop sweep), leave it working.
  3. Start a long unattended run in project B (bmad-loop run) while A is still live.
  4. Let both drive dev sessions for ~1.5 h.
  5. Watch ~/.psmux/autorename.log and the machine's process count.

Observed timeline from my two projects:

time event
14:18:07 project A starts a sweep run
14:27:26 A's bundle dev-1 session starts
15:21:14 project B starts a story run — both runs now live
15:21:20 B's dev-1 session starts; this is B's journal's last entry
15:58–15:59 autorename.log records snapshot_entries=754..785 per scan
16:02:07 A starts dev-2 after a failed verify
16:43:30 A's dev-2 pane log stops mid-frame
16:43:42 B's dev-1 pane log stops mid-frame — 12 s apart
17:00:11 Kernel-Power id 41, BugcheckCode=0, no minidump
Expected behavior

Windows that bmad-loop creates with an explicit -n <name> should not pay a recurring whole-machine process-table scan to compute a name that was already supplied, and concurrent runs in unrelated projects should not compound each other's load through the shared multiplexer server.

Actual behavior

Both panes stopped mid-spinner while the agents were actively working (Percolating…, still thinking with high effort). No error, no crash, no adapter fault in either journal. BugcheckCode=0 with no dump and no WER-SystemErrorReporting entry means this was a hang, not a bugcheck — the system stopped scheduling and I held the power button ~17 minutes later.

Measurements from that afternoon:

  • Four distinct roots (panes) appear in autorename.log: 12032, 34668, 53064, 61828.
  • They are concurrent, not serialized — e.g. 15:00:26.193 root=34668 and 15:00:26.227 root=53064, 34 ms apart.
  • Cadence is 1 Hz per root: 14:58:46.160, :47.161, :48.164, :49.177, :50.187.
  • snapshot_entries ranged 605–840. The same machine idles at 467 (Get-CimInstance Win32_Process), so the table each scanner walked was inflated 1.3–1.8× by the two runs themselves.
  • A full process-table snapshot costs ~168 ms here via CIM. The native CreateToolhelp32Snapshot path is cheaper, but it is the same O(all processes) walk, it takes a system-wide lock, and it contends with the process creation the agent sessions do continuously.

That is the feedback loop: more concurrent runs → more panes → more whole-machine scanners → each walking a table the other runs are inflating and churning.

Suggested fix

Set automatic-rename off on the windows bmad-loop creates. It looks free and strictly correct here:

  • bmad-loop already passes -n <name>, so the derived name is pure waste.
  • adapters/psmux_backend.py already notes that automatic-rename is the one builtin window option with true per-window storage, so it can be set per window without touching the user's globals or other applications' windows.
  • It also removes a live conflict: psmux #266 and #169 are automatic-rename overriding an explicit -n NAME, which is exactly what bmad-loop asks for.

Scoping it per window rather than per session or globally keeps it limited to bmad-loop's own panes and leaves interactive windows alone.

Which area is this for?

multiplexer / adapters

bmad-loop Version

0.10.0 (installed as uv tool install 'bmad-loop[tui] @ git+https://github.com/bmad-code-org/[email protected]'); v0.11.0 sources checked and unchanged in this respect

Which coding CLI are you using?

claude (dev and review, both projects)

Operating System

Windows 11 Pro 26200, 31 GB RAM, psmux 3.3.7 (win32 platform default backend), no ~/.psmux.conf

Relevant log output

~/.psmux/autorename.log, one scan per pane per second:

[14:58:58.956] root=53064 snapshot_entries=660
[14:58:58.956] root=53064 no_direct_children
[14:58:58.957] pid=53064 fg_child=None (BFS found nothing)
[14:58:59.957] root=53064 snapshot_entries=656
...
[15:59:11.229] root=61828 snapshot_entries=785
[15:59:11.229]   direct_child: pid=31788 name=bmad-loop.exe
[15:59:11.229] root=61828 immediate_child=31788 name=bmad-loop.exe
[15:59:11.230] pid=61828 fg_child=31788 name=Some("bmad-loop")

Windows event, ~17 min after both panes went silent:

Microsoft-Windows-Kernel-Power  id 41  Critical  2026-08-19 17:00:11
BugcheckCode=0, no minidump, no WER-SystemErrorReporting entry
Related
  • psmux #459 — unbounded psmux.exe growth with multiple heavy TUI panes; closed not-reproducible, but the reporter's field case ("~400 processes, system extremely unresponsive, had to force-kill to recover") was never explained.
  • psmux #266 / #169 — automatic-rename overriding explicit -n NAME.

Happy to test a patch — I can reproduce the two-project load on demand.

Lenguaje dominante
Python
Estrellas
146
Forks
68
Merge medio
1 d 19 h
PR fusionados (30 d)
44

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 bmad-code-org/bmad-loop

Todos los issues de bmad-code-org/bmad-loop

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.