diff options
| author | blasty <peter@haxx.in> | 2026-07-23 23:43:37 +0200 |
|---|---|---|
| committer | blasty <peter@haxx.in> | 2026-07-23 23:43:37 +0200 |
| commit | 827219159c879f4a4b696520c7efb84012125d58 (patch) | |
| tree | 32e22d825cb1ab013ef8ce628f027e207ba6193d /server/patch_server.py | |
| parent | ux: show TUI chrome + a "loading…" overlay during binary open/analysis (diff) | |
| download | ida-tui-827219159c879f4a4b696520c7efb84012125d58.tar.gz ida-tui-827219159c879f4a4b696520c7efb84012125d58.tar.xz ida-tui-827219159c879f4a4b696520c7efb84012125d58.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 'server/patch_server.py')
0 files changed, 0 insertions, 0 deletions