diff options
| author | blasty <blasty@local> | 2026-07-24 01:42:43 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-24 01:42:43 +0200 |
| commit | 784df98d19b70eca5906ce0ac7fcf2bfcd0f3515 (patch) | |
| tree | 21a8bc2b8fce7df70a79ac0361cc51c70eb64061 /server/patch_server.py | |
| parent | app: --backend {mcp,worker} — run the TUI on our idalib worker (migration s... (diff) | |
| download | ida-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
