[PR #5356] [MERGED] fix(ghidra): explain server restart for timeout recovery #6891

Closed
opened 2026-11-01 21:43:52 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5356
Author: @gensokyo-dev
Created: 10/20/2026
Status: ✅ Merged
Merged: 10/20/2026
Merged by: @gensokyo-dev

Base: main ← Head: fix/ghidra-analysis-timeout


📝 Commits (1)

  • 0c84279 fix(ghidra): explain server restart for timeout recovery

📊 Changes

7 files changed (+71 additions, -4 deletions)

View changed files

📝 .agents/skills/reverse-engineer-anything/SKILL.md (+7 -1)
📝 .agents/skills/reverse-engineer-anything/references/native-and-artifacts.md (+30 -0)
📝 docs/installation.md (+18 -0)
📝 docs/mcp-contracts.md (+7 -0)
📝 src/generatedPackageMetadata.ts (+1 -1)
📝 src/ghidra/GhidraProvider.behavior.test.ts (+6 -0)
📝 src/ghidra/GhidraProviderClient.ts (+2 -2)

📄 Description

Summary

A Ghidra startup timeout told analysts to change the environment and reopen the target. REA snapshots configuration when the server starts, so close/reopen on the existing server still uses the old deadline and repeats the cold import. This can make the configurable 330-second default look like a fixed technical limit.

The shared CLI/MCP error now explains Evidence export, cleanup, changing the server launch environment, restarting REA, reconnecting MCP, and allowing enough client request time. The bundled skill (version 43) and owning guides give the same recovery flow and a concrete CLI retry. Analyzer exclusions explicitly reduce coverage. Engine defaults and analysis contracts are unchanged.

Related to #3509; this addresses timeout recovery guidance, not the separate transport-loss report or pending progress/cache designs.

Validation

  • Regression: the new restart assertion failed on the old guidance (129 other tests passed); 198 provider/config tests pass after the fix and again after rebasing onto 58d604330.
  • 100 focused boundary tests passed: provider startup, cancellation, retained cleanup, reopen, and CLI/SDK MCP diagnostic projection.
  • npm run check, npm run docs:check (including 5 consistency tests), npm run verify:package, and npm pack --dry-run passed. Package verification covered installed CLI/MCP, Evidence, skill installation/update, setup/uninstall, and cleanup. Package/boundary checks preceded the final one-commit main rebase; full static/docs checks and the real MCP proof were repeated afterwards.
  • Real stdio MCP on the current source tree: two 1 ms startup failures demonstrate that changing the parent's environment and reopening do not change the existing server. Restarting with 120,000 ms succeeds, independently checks the source-built input * 7 + 3 function, reuses a warm overview, exports its digest-linked Evidence, and removes all owned temporary roots/processes. Whole harness: 132.80 s elapsed, 65.59 s CPU, 1036.0 MiB cgroup peak.

Real Ghidra 12.1.4 / Temurin 21.0.12.1, Linux x86-64; static analysis of the public gsudo 2.5.1 x64 EXE (5,915,592 bytes; SHA-256 47d02ca82bc31ae9f4b6cc1e76dceffe610b9b664d3c18a17e0403463c48d749):

Startup budget Elapsed Family CPU Family peak Outcome
Default 330,000 ms 340.06 s 250.60 s 1235.4 MiB Typed timeout; runtime/processes removed
Fresh process, 1,800,000 ms 326.37 s 324.85 s 1213.4 MiB Success: 18,679 procedures, 4,006 defined strings; cleanup verified

| Fresh process, 1,800,000 ms, 75% CPU | 590.75 s | 404.45 s | 1226.6 MiB | Success beyond 330 s; same counts; cleanup verified |

The final-tree 75% run matched the previous success's normalized result, target digest, analysis profile, and coverage limitations exactly. The final commit amends committer identity to gensokyo-dev; its tested source tree is unchanged.

Fresh ephemeral sessions, default analyzers, 1536M configured Java heap, one CPU, 6 GiB family hard limit / 5 GiB early stop / no swap. Kernel cgroup v2 CPU and memory.peak counters include the harness and file cache, witnessed at payload exit with only the observer remaining. The first baseline overlapped a check on the same CPU, so these are recovery observations, not a speed comparison. The original reporter's EXE was not supplied; real Windows/macOS were not run. Defined-inventory and unknown PDB coverage remain in Evidence.

Two local check attempts were stopped at the 5 GiB guard without OOM. Serialized checks with an 8 GiB hard / 7 GiB early limit passed; final check peak was 5105.1 MiB. All measured lanes reported zero OOM kills.

Context: the error guidance estimate increases from 98 to 141 cl100k_base tokens. The complete current MCP proof, including both connections, failed attempts and replies, estimates 76,850 serialized wire tokens; it uses known tools without tools/list. Schema/prompt loading and actual model usage are unmeasured. No token reduction or analysis speedup is claimed.

Greptile completed review of the final head with 5/5 confidence and no actionable findings. Codex automated review was unavailable because the repository review quota was exhausted.

Author readiness

Human owner: @gensokyo-dev

The human owner explicitly delegated filling readiness, opening ready for review, and merging in the task request. Diff review and validation were performed by the agent under that delegation; no separate human diff review is claimed.

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/5356 **Author:** [@gensokyo-dev](https://github.com/gensokyo-dev) **Created:** 10/20/2026 **Status:** ✅ Merged **Merged:** 10/20/2026 **Merged by:** [@gensokyo-dev](https://github.com/gensokyo-dev) **Base:** `main` ← **Head:** `fix/ghidra-analysis-timeout` --- ### 📝 Commits (1) - [`0c84279`](https://github.com/morluto/rea/commit/0c84279f38c91e01dcd14b937dcf27b49c8df660) fix(ghidra): explain server restart for timeout recovery ### 📊 Changes **7 files changed** (+71 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `.agents/skills/reverse-engineer-anything/SKILL.md` (+7 -1) 📝 `.agents/skills/reverse-engineer-anything/references/native-and-artifacts.md` (+30 -0) 📝 `docs/installation.md` (+18 -0) 📝 `docs/mcp-contracts.md` (+7 -0) 📝 `src/generatedPackageMetadata.ts` (+1 -1) 📝 `src/ghidra/GhidraProvider.behavior.test.ts` (+6 -0) 📝 `src/ghidra/GhidraProviderClient.ts` (+2 -2) </details> ### 📄 Description ## Summary A Ghidra startup timeout told analysts to change the environment and reopen the target. REA snapshots configuration when the server starts, so close/reopen on the existing server still uses the old deadline and repeats the cold import. This can make the configurable 330-second default look like a fixed technical limit. The shared CLI/MCP error now explains Evidence export, cleanup, changing the **server launch** environment, restarting REA, reconnecting MCP, and allowing enough client request time. The bundled skill (version 43) and owning guides give the same recovery flow and a concrete CLI retry. Analyzer exclusions explicitly reduce coverage. Engine defaults and analysis contracts are unchanged. Related to #3509; this addresses timeout recovery guidance, not the separate transport-loss report or pending progress/cache designs. ## Validation - Regression: the new restart assertion failed on the old guidance (129 other tests passed); 198 provider/config tests pass after the fix and again after rebasing onto `58d604330`. - 100 focused boundary tests passed: provider startup, cancellation, retained cleanup, reopen, and CLI/SDK MCP diagnostic projection. - `npm run check`, `npm run docs:check` (including 5 consistency tests), `npm run verify:package`, and `npm pack --dry-run` passed. Package verification covered installed CLI/MCP, Evidence, skill installation/update, setup/uninstall, and cleanup. Package/boundary checks preceded the final one-commit main rebase; full static/docs checks and the real MCP proof were repeated afterwards. - Real stdio MCP on the current source tree: two 1 ms startup failures demonstrate that changing the parent's environment and reopening do not change the existing server. Restarting with 120,000 ms succeeds, independently checks the source-built `input * 7 + 3` function, reuses a warm overview, exports its digest-linked Evidence, and removes all owned temporary roots/processes. Whole harness: 132.80 s elapsed, 65.59 s CPU, 1036.0 MiB cgroup peak. Real Ghidra 12.1.4 / Temurin 21.0.12.1, Linux x86-64; static analysis of the public gsudo 2.5.1 x64 EXE (5,915,592 bytes; SHA-256 `47d02ca82bc31ae9f4b6cc1e76dceffe610b9b664d3c18a17e0403463c48d749`): | Startup budget | Elapsed | Family CPU | Family peak | Outcome | | --- | ---: | ---: | ---: | --- | | Default 330,000 ms | 340.06 s | 250.60 s | 1235.4 MiB | Typed timeout; runtime/processes removed | | Fresh process, 1,800,000 ms | 326.37 s | 324.85 s | 1213.4 MiB | Success: 18,679 procedures, 4,006 defined strings; cleanup verified | | Fresh process, 1,800,000 ms, 75% CPU | 590.75 s | 404.45 s | 1226.6 MiB | Success beyond 330 s; same counts; cleanup verified | The final-tree 75% run matched the previous success's normalized result, target digest, analysis profile, and coverage limitations exactly. The final commit amends committer identity to `gensokyo-dev`; its tested source tree is unchanged. Fresh ephemeral sessions, default analyzers, 1536M configured Java heap, one CPU, 6 GiB family hard limit / 5 GiB early stop / no swap. Kernel cgroup v2 CPU and `memory.peak` counters include the harness and file cache, witnessed at payload exit with only the observer remaining. The first baseline overlapped a check on the same CPU, so these are recovery observations, **not a speed comparison**. The original reporter's EXE was not supplied; real Windows/macOS were not run. Defined-inventory and unknown PDB coverage remain in Evidence. Two local check attempts were stopped at the 5 GiB guard without OOM. Serialized checks with an 8 GiB hard / 7 GiB early limit passed; final check peak was 5105.1 MiB. All measured lanes reported zero OOM kills. Context: the error guidance estimate increases from 98 to 141 `cl100k_base` tokens. The complete current MCP proof, including both connections, failed attempts and replies, estimates 76,850 serialized wire tokens; it uses known tools without `tools/list`. Schema/prompt loading and actual model usage are unmeasured. No token reduction or analysis speedup is claimed. Greptile completed review of the final head with 5/5 confidence and no actionable findings. Codex automated review was unavailable because the repository review quota was exhausted. ## Author readiness Human owner: @gensokyo-dev The human owner explicitly delegated filling readiness, opening ready for review, and merging in the task request. Diff review and validation were performed by the agent under that delegation; no separate human diff review is claimed. - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:43:52 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#6891
No description provided.