mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-28 02:56:36 -04:00
Matthew Stanley
40e9b79fb7
Root cause of the apparent "freeze" observed after issuing debug commands: tools/_dbg.py and similar one-shot Python clients open a fresh TCP connection per command, send their request, read the reply, then close. If the command was `pause` or `step`, the runtime is left with s_paused=1 and no client to issue `continue`. The runtime then spins in debug_server_wait_if_paused() forever — SDL window stops updating, frame counter stuck — and the user reads this as "frozen" even though the process is healthy. The legitimate "open a persistent connection, pause, investigate, continue" workflow keeps the socket open across all of that, so the disconnect-then-clear behavior doesn't affect it. Fix: when the client disconnects, clear s_paused / s_step_count / s_run_to. Verified by sending pause via _dbg.py and watching the frame counter keep advancing on the next freeze_check query. Visibility: freeze_check now reports frame_count, paused, step_count, run_to, client_connected. A "frozen" state can now be classified without guessing — paused=1 = leftover-pause, paused=0 + frame_count stuck = real game-loop wedge. Ring cap reductions: - WRITE_TRACE_CAP 4M -> 256K (-360 MB worst-case) - SIO_PC_TRACE_CAP 4M -> 256K - MMIO_TRACE_CAP 4M -> 256K - FN_TRACE_CAP 1M -> 256K - FN_EXIT_TRACE_CAP 4M -> 256K At 60Hz and ~thousand events/frame each ring still covers ~4 sec — plenty for the diagnostic flows we actually run. Worst-case runtime RSS drops from ~1 GB potential to ~100 MB. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>