Recover from a crashed IDA session instead of failing forever - #226
Open
subwire wants to merge 1 commit into
Open
Recover from a crashed IDA session instead of failing forever#226subwire wants to merge 1 commit into
subwire wants to merge 1 commit into
Conversation
A server that dies uncleanly leaves IDA's unpacked database components (.id0/.id1/.id2/.nam/.til) in the project directory. IDA reads those as a database that is still open and refuses to reopen it, so **every** subsequent load of that binary fails with "Failed to open database" -- permanently, for that project, with nothing in the message to suggest a remedy. Reproduced deterministically: load a binary, `kill -9` the server, load again -> failure. Wipe the project dir -> works. The same binary failed up to 7 times in a row during a benchmark because nothing ever cleared it. Measured on a 40-binary run: **64 of 80** DecLib failures were this. It was also the single largest driver of wasted agent effort -- 77 commands spent reading server logs across six challenges, nearly as many as were spent on analysis, because the error gives no hint that the project is poisoned. cmd_load now clears the unpacked components before spawning, but only when no live server owns the project (the existing checks above have already returned or torn those down), so this cannot disturb a running session. The saved .i64/.idb is deliberately preserved: that is where annotations live. Verified end-to-end -- comment, save, `kill -9`, reload, and the comment is still there. Only the unpacked cache is removed, and reanalysis regenerates it. Scoped to the IDA backend; a no-op for ghidra/angr/binja. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A decompiler server that dies uncleanly leaves IDA's unpacked database components (
.id0,.id1,.id2,.nam,.til) in the project directory. IDA reads those as a database that is still open and refuses to reopen it — so every subsequent load of that binary fails, permanently, for that project:Nothing in the message suggests the project is poisoned or how to clear it.
Reproduced deterministically:
Why it matters
We ran 40 binaries through DecLib as the sole decompiler interface and compared against an MCP-based baseline. 64 of 80 DecLib failures were this one bug. The same binary failed up to 7 times in a row, because nothing ever cleared the residue and the agent had no way to know it needed to.
It was also the biggest single driver of wasted effort. Across six challenges, agents spent 77 commands reading server logs — nearly as many as they spent on actual analysis (83) — trying to work out why loads kept failing.
The distinction that makes a safe fix possible
.i64+ unpacked componentsstop --save.i64only (IDA repacks) — reload works.i64+ orphaned unpacked components → poisonedSo unpacked components with no live server are unambiguously crash residue, and the user's actual work is in the
.i64.Change
cmd_loadclears the unpacked components before spawning — but only when no live server owns the project (the existing--replace/ already-loaded checks above have already returned or torn those down), so a running session is never disturbed.The
.i64/.idbis deliberately preserved. Verified end-to-end: set a comment,save,kill -9the server, reload — the comment is still there. Only the regenerable cache is removed.Scoped to the IDA backend; a no-op for ghidra/angr/binja.
Tests
Five cases: removes the unpacked components; preserves the saved
.i64; no-op for other backends; no-op when nothing is stale; tolerates a missing/None project dir.🤖 Generated with Claude Code