| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
The "auto-analyzing…" note crammed the "first open of a big binary can take a
while" caveat onto one line that overflowed the fixed-width splash box (it showed
truncated as "…first open of a big binary can"). Move the caveat to the splash's
static help line, keep the dynamic note short, and (in app.py, already committed)
widen the box to 72 and let the note/help wrap (height: auto) as a safety net.
|
| |
|
|
|
|
|
|
|
|
|
| |
The supervisor opens + auto-analyzes its seed binary BEFORE it binds the port
(idalib_supervisor.main), so the whole "starting analysis server" wait is really
IDA running initial auto-analysis. Relabel the overlay notes to say so:
"starting IDA — initial auto-analysis of <bin>…" then
"auto-analyzing <bin>… (Ns) first open of a big binary can take a while".
Message-only change in _ensure_server (with the progress callback); no behavior
change. Verified the emitted notes with a mocked server-up poll.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The remaining "long wait with no feedback" was the launcher's _ensure_server: it
started the supervisor and blocked ~10s polling for the port BEFORE the TUI (and
its overlay) existed. Only a one-line stderr message covered it.
Move that wait behind the overlay. The launcher now only does instant checks
(sweep stale locks if the server is down, honor --no-server) and hands the binary
straight to the TUI with ensure_server=True. The TUI's _connect starts the
server itself and narrates it in the loading overlay ("starting analysis
server… (Ns)") before opening/analyzing the binary. idb_open is idempotent, so an
already-open session is still adopted instantly (the launcher no longer needs to
probe sessions).
_ensure_server gained a progress callback so it reports to the overlay instead of
stderr (which would corrupt the TUI screen).
Verified with the server DOWN: chrome + overlay appear within ~0.5s, notes go
"starting analysis server… (0s)" -> "opening echo — analyzing…" ->
"echo — 128 functions…" -> land on main. Pilot suite (db/ensure_server=False path)
green: startup/palette/view_toggle/disasm_nav/search/rename/follow_xrefs/
decomp_nav/mouse/listing_view/continuous_view/func_banners.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two parts:
1) A LoadingScreen modal is pushed on mount and dismissed once we land on a
function (or the symbol picker). Its note line mirrors _status, so you see
"opening… analyzing", then "N functions…", instead of staring at empty panes.
Esc hides it if you'd rather watch the status bar.
2) The real fix for the dead air BEFORE the TUI drew anything: the launcher used
to block on idb_open (full analysis of a big binary) *before* starting the
TUI, so the overlay only flashed after the wait was already over. Now the
launcher only adopts an already-open session (instant); otherwise it defers
the open to the TUI via open_path, and _connect does idb_open (with the
crashed-worker lock-sweep + retry moved here) while the chrome + overlay are
on screen. Added a ttl arg to IdaTui for the deferred open.
Verified: overlay pushed on mount, present through open+function-load, dismissed
on landing; TUI-driven open (open_path, db=None) opens echo and lands on main
with notes "opening echo — analyzing…" -> "echo — 128 functions…"; startup/
palette/view_toggle/disasm_nav/search/rename/follow_xrefs/decomp_nav/mouse/
listing_view/continuous_view/func_banners green.
|
|
|
A caveman entry point so you don't hand-craft the plumbing every time. It:
* ensures the ida-pro-mcp supervisor is up — starts spawn.sh detached
(start_new_session, tmux-free) and waits for the port if it's down;
* recovers a binary wedged by a hard-killed worker — sweeps the stale
unpacked .id0/.id1/.id2/.nam/.til next to the .i64 and retries (the packed
.i64 is never touched);
* adopts an already-open session for the same binary (idempotent), else
idb_opens it with a sane idle-TTL;
* launches the TUI attached to that session with keepalive on.
./ida-tui /path/to/binary # open a binary and drive it
./ida-tui # attach to the sole session
./ida-tui --db <id> # attach to a specific session
Pieces: idatui/launch.py (logic, reuses pane.py's server probe), a repo-root
`ida-tui` sh wrapper (resolves ~/ida-venv python, keeps idatui importable from
any cwd), and an `ida-tui` console-script in pyproject. --help works without
textual (app imported late). README documents both the one-liner and the
manual recovery. gitignore bin/ (binary targets, like targets/).
Verified live: ensure_server up-detection, open, adopt (same session id), and
lock-sweep all work against a running supervisor.
|
