morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4241] [Bug] Ghidra "Java heap space" during import is reported as execution_failure ("run rea doctor"), not a memory resource constraint #1668

New issue

Closed

opened 2026-10-16 21:08:47 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-16 21:08:47 +00:00

Owner

Originally created by @Rinkia on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4241

Before submitting

I searched the open and closed issues for a related report (OutOfMemoryError, Java heap space ghidra, ghidra heap execution_failure). Sibling: #3517 (the same pattern for JADX). Related: #1048 and #3751 (pre-imported projects for large binaries).
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

rea inspect … --provider ghidra on Debian bookworm's hugo (Go 1.19.6, 53 MB) fails after 773 s with:

{"code":"execution_failure",
 "message":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.",
 "details":{"provider_id":"ghidra","operation":"list_documents", "diagnostics":{…}}}

The cause is only visible deep in details.diagnostics.stdout.text:

ERROR Abort due to Headless analyzer error: Java heap space (HeadlessAnalyzer) java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3482)
	at ghidra.program.util.VarnodeContext.pushMemState(VarnodeContext.java:2026)
	…
	at ghidra.app.plugin.core.analysis.GolangSymbolAnalyzer$PropagateRttiBackgroundCommand.fixupRttiCallsitesInFunc(GolangSymbolAnalyzer.java:1128)

This was with GHIDRA_HEADLESS_MAXMEM=4G in a 5 GB container. The guidance points away from the fix: rea doctor reports Ghidra healthy, and a larger heap (or disabling the analyzer) is the relevant change, so the unchanged request isn't the only option.

docs/binary-diagnostics.md states the intended contract for memory failures: "Memory allocation failures use resource_constraint, with effective resource limits (or an explicit unknown) and memory-specific recovery guidance." No Ghidra path recognizes OutOfMemoryError/Java heap space; a search of src/ on main @ e2db76801 finds no match.

Related, smaller point. Hugo extended 0.168.0 (Go 1.27.2, 62 MB, cgo) produces provider_timeout at the default 330 s and again with REA_GHIDRA_STARTUP_TIMEOUT_MS=1800000. The message is the generic "Analysis took too long. Try a smaller request, then run rea doctor if it continues." (src/domain/analysisErrorPresentation.ts:358), and it doesn't mention REA_GHIDRA_STARTUP_TIMEOUT_MS or REA_GHIDRA_DISABLED_ANALYZERS, which docs/installation.md documents for this case. In that log, Ghidra also reports ERROR Untested Go version [1.27.2] (GoRttiMapper) followed by unable to extract Go RTTI info, which explains why its Go analyzers can't help on this binary. That too is visible only in the raw stdout.

Reproduction

Debian bookworm hugo:
- apt-get download hugo: hugo_0.111.3-1_amd64.deb, verified by apt against the signed InRelease.
- .deb sha256 6c3508f7b0f0009e6f774806dcb061d9ad24782d71b1688c700c016772df586e.
- /usr/bin/hugo is 53,465,504 bytes, sha256 88056a86368f9b645b897d0237459ca43a8ea12913902f495fbdabe7ec567d64, Go 1.19.6, GOPATH build.
Hugo extended 0.168.0: hugo_extended_0.168.0_linux-amd64.tar.gz from the GitHub release, verified with hugo_0.168.0_checksums.txt; hugo sha256 8bfae845201cec7ce3e7df6009c972cbfe7c08ef7f54efe33b5380d746278dee.

docker run --rm --memory 5g -e GHIDRA_HEADLESS_MAXMEM=4G -e REA_GHIDRA_STARTUP_TIMEOUT_MS=1800000 \
  -v …:/targets:ro rea inspect /targets/hugo --provider ghidra --json
# Debian hugo: execution_failure after 773 s (OutOfMemoryError in stdout)
# Hugo extended 0.168.0: provider_timeout after 1804 s

Expected behavior

When the Ghidra process output contains java.lang.OutOfMemoryError (or the headless "Abort due to … Java heap space"), report resource_constraint / resource: "memory". Include the effective GHIDRA_HEADLESS_MAXMEM (or unknown) and memory-specific guidance: raise the heap within the container or host limit, or disable the heavy analyzer via REA_GHIDRA_DISABLED_ANALYZERS. This matches the documented contract and the fix requested for JADX in #3517.
For a Ghidra startup provider_timeout, name REA_GHIDRA_STARTUP_TIMEOUT_MS (with its current value) and REA_GHIDRA_DISABLED_ANALYZERS in the remediation, rather than only "try a smaller request". A smaller request isn't possible for a whole-program import.
Optionally, lift known Ghidra analyzer errors such as Untested Go version into Evidence limitations.

Impact and scope

Large Go binaries (and probably other large targets) on the default container sizes in REA's Docker guidance. A user following the message runs rea doctor, sees a healthy result and has no lead.
I didn't test whether a larger heap lets Debian hugo finish: the Docker Desktop VM here is about 7.6 GB, and an earlier uncapped Ghidra run crashed it.

REA version

Executed on rea-agents@6.5.0, Ghidra 12.1.4, Temurin JDK 21.0.12. The classification is unchanged on main @ e2db76801 (source search).

Runtime and platform

rea Docker image (Linux x64) on Windows 11 / Docker Desktop.

Target and artifact context

Public Debian package and public GitHub release (Apache-2.0).

Interface

CLI.

Originally created by @Rinkia on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4241 ### Before submitting - [x] I searched the open and closed issues for a related report (OutOfMemoryError, Java heap space ghidra, ghidra heap execution_failure). Sibling: #3517 (the same pattern for JADX). Related: #1048 and #3751 (pre-imported projects for large binaries). - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `rea inspect … --provider ghidra` on Debian bookworm's `hugo` (Go 1.19.6, 53 MB) fails after 773 s with: ```json {"code":"execution_failure", "message":"Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.", "details":{"provider_id":"ghidra","operation":"list_documents", "diagnostics":{…}}} ``` The cause is only visible deep in `details.diagnostics.stdout.text`: ```text ERROR Abort due to Headless analyzer error: Java heap space (HeadlessAnalyzer) java.lang.OutOfMemoryError: Java heap space at java.base/java.util.Arrays.copyOf(Arrays.java:3482) at ghidra.program.util.VarnodeContext.pushMemState(VarnodeContext.java:2026) … at ghidra.app.plugin.core.analysis.GolangSymbolAnalyzer$PropagateRttiBackgroundCommand.fixupRttiCallsitesInFunc(GolangSymbolAnalyzer.java:1128) ``` This was with `GHIDRA_HEADLESS_MAXMEM=4G` in a 5 GB container. The guidance points away from the fix: `rea doctor` reports Ghidra healthy, and a larger heap (or disabling the analyzer) is the relevant change, so the unchanged request isn't the only option. `docs/binary-diagnostics.md` states the intended contract for memory failures: "Memory allocation failures use `resource_constraint`, with effective resource limits (or an explicit unknown) and memory-specific recovery guidance." No Ghidra path recognizes `OutOfMemoryError`/`Java heap space`; a search of `src/` on `main` @ `e2db76801` finds no match. **Related, smaller point.** Hugo extended 0.168.0 (Go 1.27.2, 62 MB, cgo) produces `provider_timeout` at the default 330 s and again with `REA_GHIDRA_STARTUP_TIMEOUT_MS=1800000`. The message is the generic "Analysis took too long. Try a smaller request, then run `rea doctor` if it continues." (`src/domain/analysisErrorPresentation.ts:358`), and it doesn't mention `REA_GHIDRA_STARTUP_TIMEOUT_MS` or `REA_GHIDRA_DISABLED_ANALYZERS`, which `docs/installation.md` documents for this case. In that log, Ghidra also reports `ERROR Untested Go version [1.27.2] (GoRttiMapper)` followed by `unable to extract Go RTTI info`, which explains why its Go analyzers can't help on this binary. That too is visible only in the raw stdout. ### Reproduction - **Debian bookworm `hugo`:** - `apt-get download hugo`: `hugo_0.111.3-1_amd64.deb`, verified by apt against the signed InRelease. - `.deb` sha256 `6c3508f7b0f0009e6f774806dcb061d9ad24782d71b1688c700c016772df586e`. - `/usr/bin/hugo` is 53,465,504 bytes, sha256 `88056a86368f9b645b897d0237459ca43a8ea12913902f495fbdabe7ec567d64`, Go 1.19.6, GOPATH build. - **Hugo extended 0.168.0:** `hugo_extended_0.168.0_linux-amd64.tar.gz` from the GitHub release, verified with `hugo_0.168.0_checksums.txt`; `hugo` sha256 `8bfae845201cec7ce3e7df6009c972cbfe7c08ef7f54efe33b5380d746278dee`. ```sh docker run --rm --memory 5g -e GHIDRA_HEADLESS_MAXMEM=4G -e REA_GHIDRA_STARTUP_TIMEOUT_MS=1800000 \ -v …:/targets:ro rea inspect /targets/hugo --provider ghidra --json # Debian hugo: execution_failure after 773 s (OutOfMemoryError in stdout) # Hugo extended 0.168.0: provider_timeout after 1804 s ``` ### Expected behavior - When the Ghidra process output contains `java.lang.OutOfMemoryError` (or the headless "Abort due to … Java heap space"), report `resource_constraint` / `resource: "memory"`. Include the effective `GHIDRA_HEADLESS_MAXMEM` (or unknown) and memory-specific guidance: raise the heap within the container or host limit, or disable the heavy analyzer via `REA_GHIDRA_DISABLED_ANALYZERS`. This matches the documented contract and the fix requested for JADX in #3517. - For a Ghidra startup `provider_timeout`, name `REA_GHIDRA_STARTUP_TIMEOUT_MS` (with its current value) and `REA_GHIDRA_DISABLED_ANALYZERS` in the remediation, rather than only "try a smaller request". A smaller request isn't possible for a whole-program import. - Optionally, lift known Ghidra analyzer errors such as `Untested Go version` into Evidence limitations. ### Impact and scope - Large Go binaries (and probably other large targets) on the default container sizes in REA's Docker guidance. A user following the message runs `rea doctor`, sees a healthy result and has no lead. - I didn't test whether a larger heap lets Debian `hugo` finish: the Docker Desktop VM here is about 7.6 GB, and an earlier uncapped Ghidra run crashed it. ### REA version Executed on `rea-agents@6.5.0`, Ghidra 12.1.4, Temurin JDK 21.0.12. The classification is unchanged on `main` @ `e2db76801` (source search). ### Runtime and platform `rea` Docker image (Linux x64) on Windows 11 / Docker Desktop. ### Target and artifact context Public Debian package and public GitHub release (Apache-2.0). ### Interface CLI.

bsakaguchi commented

2026-10-16 21:08:48 +00:00

Author

Owner

@RishTheFish21 commented on GitHub (Oct 15, 2026):

I'd like to take this one. Plan: when Ghidra's retained output shows java.lang.OutOfMemoryError, report resource_constraint with resource "memory" instead of execution_failure, include the -Xmx REA launched with in reported_limits, and point the remediation at GHIDRA_HEADLESS_MAXMEM / REA_GHIDRA_DISABLED_ANALYZERS. I'll leave the startup-timeout wording for a separate PR unless you'd rather have both together.

@RishTheFish21 commented on GitHub (Oct 15, 2026): I'd like to take this one. Plan: when Ghidra's retained output shows java.lang.OutOfMemoryError, report resource_constraint with resource "memory" instead of execution_failure, include the -Xmx REA launched with in reported_limits, and point the remediation at GHIDRA_HEADLESS_MAXMEM / REA_GHIDRA_DISABLED_ANALYZERS. I'll leave the startup-timeout wording for a separate PR unless you'd rather have both together.

bsakaguchi commented

2026-10-16 21:08:48 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 16, 2026):

Cross-referencing: this pattern is now tracked under the JVM Provider Heap Exhaustion cluster in #4330, alongside sibling issue #3517 (the exact same Java heap space / misleading rea doctor remediation behavior for JADX).

Consolidating both under a single typed resource_constraint error with memory-specific guidance (GHIDRA_HEADLESS_MAXMEM, REA_JADX_HEAP_MIB) will resolve the misclassification uniformly across all JVM providers.

@matbrgz commented on GitHub (Oct 16, 2026): Cross-referencing: this pattern is now tracked under the JVM Provider Heap Exhaustion cluster in **#4330**, alongside sibling issue **#3517** (the exact same `Java heap space` / misleading `rea doctor` remediation behavior for JADX). Consolidating both under a single typed `resource_constraint` error with memory-specific guidance (`GHIDRA_HEADLESS_MAXMEM`, `REA_JADX_HEAP_MIB`) will resolve the misclassification uniformly across all JVM providers.

bsakaguchi referenced this issue

2026-10-17 21:01:31 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi closed this issue

2026-10-17 21:02:47 +00:00

bsakaguchi referenced this issue

2026-10-31 00:54:32 +00:00

[PR #1668] [MERGED] test(ci): stabilize JADX recovery and ignore generated reports #4736