diff options
| author | blasty <blasty@local> | 2026-07-23 23:43:37 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-23 23:43:37 +0200 |
| commit | 0d7e5c7910ce05c1e8ce1237a14f6e4af9f90701 (patch) | |
| tree | 17ffc98b1f01b5b473d4eadb7fd96d2da7dec571 /docs | |
| parent | ux: show TUI chrome + a "loading…" overlay during binary open/analysis (diff) | |
| download | ida-tui-0d7e5c7910ce05c1e8ce1237a14f6e4af9f90701.tar.gz ida-tui-0d7e5c7910ce05c1e8ce1237a14f6e4af9f90701.tar.xz ida-tui-0d7e5c7910ce05c1e8ce1237a14f6e4af9f90701.zip | |
launch: sweep a crashed worker's stale DB locks before starting the supervisor
A binary whose worker was hard-killed mid-analysis leaves unpacked .id0/.id1/
.id2/.nam/.til files (no .i64). The supervisor is seeded with the target and
opens it on startup, so a wedged DB there crash-loops the whole supervisor
("Failed to open initial binary: Remote end closed connection") and the launcher
reports "supervisor exited during startup" -- before the TUI's own open-time
recovery can ever run.
When the launcher is about to start a fresh supervisor (server is down, so
nothing can hold the DB), proactively sweep the target's stale unpacked lock
files first (never the packed .i64). Safe because no server == no live session.
Verified: after clearing bash's stale locks the supervisor starts and stays up
20/20 checks over 20s with no crash loop and a clean log.
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions