ida-tui.git/.gitignore, branch pre-codemode

Stop tracking 157MB of core dumps, and ignore them

2026-08-07T07:15:53Z

Two core dumps were swept into 7e4b593 by an 'add -A' commit. idalib segfaults readily under differential probing (running two revisions of a tool against one cfunc drops two SWIG item objects on the same ctree), so this will recur.

tests: run the scenario suite on a scratch copy, not the tracked target

2026-07-26T19:02:47Z

The suite edits the database — defines code, undefines items, renames, comments — and IDA saves all of it. Running that against targets/echo.i64 meant every run inherited the last one's damage. That cost real time twice. decomp_follow_self "started failing" with no code change, and stayed failing until the .i64 was deleted; an edit-position check looked flaky about one run in three and I nearly reported it as an async race. Both were the database drifting. A suite whose result depends on its own history cannot be trusted to accuse the code — and it had been quietly laundering bad conclusions for however long. Now the suite copies the binary into a temp dir and seeds it from a golden database (.pristine.i64) that nothing ever writes back to. Every run starts from identical bytes; the tracked target is never opened. The golden copy is built once, on first run, by analysing and saving before any scenario runs — so it costs one analysis rather than one per run. Rebuilt automatically if the binary is newer. Verified: two consecutive full runs both 209/0; targets/echo.i64 no longer exists after a run; a deliberately corrupted targets/echo.i64 is ignored completely (11/0 with junk in place, and the junk untouched afterwards); no temp directories leak. The other suites were already clean for the same reason, by different means: test_blob_ui builds a throwaway binary, test_project_ui stages copies, and test_thumb_ui deletes the .i64 before each phase because the T flag and the segment's bitness are saved in it.

launch: `ida-tui foo.elf` one-shot wrapper (server + locks + session)

2026-07-22T22:14:59Z

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 # 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.

stress paging on 10k-func binary; document scale constraints

2026-07-09T09:35:24Z

Measured against libcrypto.so.3 (10,092 funcs, biggest 52,120 insns): - list_* count cap ~700, disasm max_instructions cap ~500, then SILENT collapse to 10 (not clamped) -> must clamp client-side (use 500). - pagination must advance by len(data); next_offset=offset+count skips data. - disasm offset paging is O(offset): 6ms@0 -> 180ms@50k, no resumable cursor -> domain layer must cache windows + prefetch + over-fetch. - include_total scans whole func (~217ms on monster) -> fetch once, cache. - decompile hard-fails on huge funcs as a soft error (code=null) -> handle. - idb_open needs a writable path for the .i64. tests/stress_paging.py: durable paging benchmark harness docs/PAGING_FINDINGS.md: constraints that drive the paging layer

persistent MCP client: warm handshake, keep-alive pool, error taxonomy, thread-safe

2026-07-09T09:14:23Z

- IDAClient: single handshake, ~7ms warm calls (vs ~60ms cold CLI) - keep-alive connection pool over http.client; concurrent-safe (40 threads OK) - grounded error taxonomy: IDAToolError on isError, soft per-item errors as data - session-expiry recovery (404 -> re-handshake -> retry), bounded transport retries - auto db-injection + resolve_db (ignores stale empty-id sessions) - live smoke test: 13/13 pass