aboutsummaryrefslogtreecommitdiffstats
path: root/server/patch_server.py
diff options
context:
space:
mode:
authorblasty <blasty@local>2026-07-24 01:42:43 +0200
committerblasty <blasty@local>2026-07-24 01:42:43 +0200
commit784df98d19b70eca5906ce0ac7fcf2bfcd0f3515 (patch)
tree21a8bc2b8fce7df70a79ac0361cc51c70eb64061 /server/patch_server.py
parentapp: --backend {mcp,worker} — run the TUI on our idalib worker (migration s... (diff)
downloadida-tui-784df98d19b70eca5906ce0ac7fcf2bfcd0f3515.tar.gz
ida-tui-784df98d19b70eca5906ce0ac7fcf2bfcd0f3515.tar.xz
ida-tui-784df98d19b70eca5906ce0ac7fcf2bfcd0f3515.zip
worker: surface the real startup failure (not just "code 1")
The worker's stderr was swallowed by the TUI, so an open failure showed only "worker exited during startup (code 1)". Now: * WorkerClient captures the worker's stdout+stderr to /tmp/idatui-worker-*.log and, on a startup exit, surfaces the last meaningful line in the error (the worker prints a clean 'WORKER-FATAL: ...' marker; _log_tail prefers it). * worker.py wraps main() to print that marker + traceback before exiting 1, and gives an ACTIONABLE open error: "failed to open <bin>: the .i64 is likely held by a running ida-mcp worker (pkill -f idalib) or wedged (delete .id0/.id1/ .id2/.nam/.til)". Also calls ida_auto.auto_wait() after open to fully match ida-mcp's session manager (open_database + auto_wait). Root cause of the reported failure is almost certainly a leftover ida-mcp worker still holding bash's .i64 from earlier --backend mcp runs: idalib can't open a database another process has locked. Fix: pkill -f idalib, then retry --backend worker; the error message now says so instead of "code 1".
Diffstat (limited to 'server/patch_server.py')
0 files changed, 0 insertions, 0 deletions