morluto/rea

Fork 0

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

[GH-ISSUE #8172] [Bug] Ghidra verification sends function Evidence beyond the default MCP input allowance #4698

New issue

Closed

opened 2026-10-31 00:52:35 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-31 00:52:35 +00:00

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

On a real Ghidra 12.1.4 run, npm run verify:ghidra failed in scripts/lib/native-value-e2e.mjs at compare_functions: its request contains two inline copies of complete analyze_function Evidence and exceeds the default MCP input allowance of 1024 elements. The server returned resource_constraint before schema validation or tool execution, and the verifier's assertion failed.

Reproduction

On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, configure GHIDRA_INSTALL_DIR and JAVA_HOME, then run npm run verify:ghidra with the default MCP input allowance. One run reached verifyNativeValueAdapters and failed as described. Frequency on other hosts or fixture layouts is unknown.

Expected behavior

The verifier should exercise comparison through a supported public workflow within default limits, preserving its actual comparison assertions and Evidence identity. analyze_function retains its complete record in the MCP session; an exact retained Evidence reference may avoid retransmitting both full records. Retain separate tests of large inline requests if they are intended, with an explicit capacity expectation.

Impact and scope

The real-provider gate cannot complete on the tested host. This is a verifier/workflow failure; it does not prove the comparison operation itself is incorrect. A separate controlled run imported two other Evidence bundles and compared retained references successfully, but did not execute this verifier's full assertion path.

REA version

Source checkout 47fa6ab3795d547207001ffb01643c0aa39dcad8.

Runtime and platform

macOS arm64, Node 24.22.1, Ghidra 12.1.4, JDK 21.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

resource_constraint: The MCP tool arguments exceed the configured input element allowance; schema validation and tool execution did not start, reported_limits.max_input_elements: 1024. Source: scripts/lib/native-value-e2e.mjs uses left: analyzed.structuredContent and right: analyzed.structuredContent. The initial attempt without JAVA_HOME failed earlier for a separate reason.

A second run set REA_MCP_MAX_INPUT_ELEMENTS=100000 in the verifier environment and failed at the same 1024-element default. Source inspection shows scripts/lib/native-value-e2e.mjs constructs a selective child environment that does not forward this setting; this retry does not establish how the full lane behaves under a larger server allowance.

A fresh npm run verify:ghidra on PR #8379 head 0212145b0 (based on main 46c13b998) reproduced the same resource_constraint at the first inline compare_functions call with the default 1,024-element allowance on macOS arm64, Ghidra 12.1.4 and JDK 21. The lane did not reach its later checks; this is a verifier failure, not a comparison result. PR #8541 proposes retained references for both comparison controls.

Combined real-provider verification on 2026-11-02

On macOS arm64 with Ghidra 12.1.4 and JDK 21, npm run verify:ghidra passed in a temporary checkout of #8379 0212145b0 with verifier-only changes from #8541 2bf92eb9, #8381 64e42396, #8536 78b6c662 and #8578 dd281594 applied. The report recorded 439 successful and 52 rejected boundary calls, regex recovery, legacy snapshot rejection, mutation snapshot lifecycle, distinct project identity refusals, complete cleanup, verified process lineage and no descendants. This is a combined run, not a clean pass of this issue’s PR or main.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8172 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior On a real Ghidra 12.1.4 run, `npm run verify:ghidra` failed in `scripts/lib/native-value-e2e.mjs` at `compare_functions`: its request contains two inline copies of complete `analyze_function` Evidence and exceeds the default MCP input allowance of 1024 elements. The server returned `resource_constraint` before schema validation or tool execution, and the verifier's assertion failed. ### Reproduction On macOS arm64 with Node 24.22.1, Ghidra 12.1.4 and JDK 21, configure `GHIDRA_INSTALL_DIR` and `JAVA_HOME`, then run `npm run verify:ghidra` with the default MCP input allowance. One run reached `verifyNativeValueAdapters` and failed as described. Frequency on other hosts or fixture layouts is unknown. ### Expected behavior The verifier should exercise comparison through a supported public workflow within default limits, preserving its actual comparison assertions and Evidence identity. `analyze_function` retains its complete record in the MCP session; an exact retained Evidence reference may avoid retransmitting both full records. Retain separate tests of large inline requests if they are intended, with an explicit capacity expectation. ### Impact and scope The real-provider gate cannot complete on the tested host. This is a verifier/workflow failure; it does not prove the comparison operation itself is incorrect. A separate controlled run imported two other Evidence bundles and compared retained references successfully, but did not execute this verifier's full assertion path. ### REA version Source checkout `47fa6ab3795d547207001ffb01643c0aa39dcad8`. ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4, JDK 21. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence `resource_constraint`: `The MCP tool arguments exceed the configured input element allowance; schema validation and tool execution did not start`, `reported_limits.max_input_elements: 1024`. Source: `scripts/lib/native-value-e2e.mjs` uses `left: analyzed.structuredContent` and `right: analyzed.structuredContent`. The initial attempt without JAVA_HOME failed earlier for a separate reason. A second run set `REA_MCP_MAX_INPUT_ELEMENTS=100000` in the verifier environment and failed at the same 1024-element default. Source inspection shows `scripts/lib/native-value-e2e.mjs` constructs a selective child environment that does not forward this setting; this retry does not establish how the full lane behaves under a larger server allowance. A fresh `npm run verify:ghidra` on PR #8379 head `0212145b0` (based on main `46c13b998`) reproduced the same `resource_constraint` at the first inline `compare_functions` call with the default 1,024-element allowance on macOS arm64, Ghidra 12.1.4 and JDK 21. The lane did not reach its later checks; this is a verifier failure, not a comparison result. PR #8541 proposes retained references for both comparison controls. ### Combined real-provider verification on 2026-11-02 On macOS arm64 with Ghidra 12.1.4 and JDK 21, `npm run verify:ghidra` passed in a temporary checkout of #8379 `0212145b0` with verifier-only changes from #8541 `2bf92eb9`, #8381 `64e42396`, #8536 `78b6c662` and #8578 `dd281594` applied. The report recorded 439 successful and 52 rejected boundary calls, regex recovery, legacy snapshot rejection, mutation snapshot lifecycle, distinct project identity refusals, complete cleanup, verified process lineage and no descendants. This is a combined run, not a clean pass of this issue’s PR or main.

bsakaguchi added the

bug

triage

labels

2026-10-31 00:52:35 +00:00

bsakaguchi commented

2026-11-01 21:11:17 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:18 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Retested the actual host-native verifier on current main 245a5818 with macOS arm64, Node 24.22.1, real Ghidra 12.1.4 and JDK 21. Running node scripts/verify-real-ghidra.mjs against a previously built runtime in an isolated checkout reproduced the default 1,024-element resource_constraint at the first compare_functions call. This was not a fresh npm run verify:ghidra build.

For a temporary experiment only, I changed both comparisons in native-value-e2e.mjs to use {kind: "retained-evidence", evidence_id: …} for the already parsed and retained dossier, without changing the comparison, unresolved-call, Evidence-bundle, CLI/MCP, or boundary assertions. The same host-native verifier then exited 0 and reported ok:true and cleanup:complete; its debug, stripped, type-layout and jump-table fixtures all ran. The first same-dossier comparison still asserted unchanged and linked Evidence; the separate unresolved-call comparison still asserted unknown. This is one host/provider run, not evidence about other lanes or platforms.

One reporting detail matters if this experiment becomes a fix: the verifier currently hard-codes inline_evidence: true in its returned summary. After this substitution the function-comparison requests are references, so that label needs to reflect what remains inline or be replaced with a precise description. Keep a separate bounded inline-input control if the lane intends to claim that coverage. No production code was changed by this experiment.

@morluto commented on GitHub (Oct 31, 2026): Retested the actual host-native verifier on current main `245a5818` with macOS arm64, Node 24.22.1, real Ghidra 12.1.4 and JDK 21. Running `node scripts/verify-real-ghidra.mjs` against a previously built runtime in an isolated checkout reproduced the default 1,024-element `resource_constraint` at the first `compare_functions` call. This was not a fresh `npm run verify:ghidra` build. For a temporary experiment only, I changed **both** comparisons in `native-value-e2e.mjs` to use `{kind: "retained-evidence", evidence_id: …}` for the already parsed and retained dossier, without changing the comparison, unresolved-call, Evidence-bundle, CLI/MCP, or boundary assertions. The same host-native verifier then exited 0 and reported `ok:true` and `cleanup:complete`; its debug, stripped, type-layout and jump-table fixtures all ran. The first same-dossier comparison still asserted `unchanged` and linked Evidence; the separate unresolved-call comparison still asserted `unknown`. This is one host/provider run, not evidence about other lanes or platforms. One reporting detail matters if this experiment becomes a fix: the verifier currently hard-codes `inline_evidence: true` in its returned summary. After this substitution the function-comparison requests are references, so that label needs to reflect what remains inline or be replaced with a precise description. Keep a separate bounded inline-input control if the lane intends to claim that coverage. No production code was changed by this experiment.

bsakaguchi commented

2026-11-01 21:11:18 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Real-provider validation of the actual open PR #8258 head 2bf92eb91964d136256116badbf50001dfabedf0: on macOS arm64, Node 24.22.1, Ghidra 12.1.4 and JDK 21, I ran npm run verify:ghidra with explicit GHIDRA_INSTALL_DIR and JAVA_HOME. The build completed and the host-native verifier exited 0 with ok: true, cleanup: complete, and no remaining owned descendants in its reported final process lineage. Its debug, stripped, type-layout and jump-table fixtures ran, including the comparison and downstream boundary assertions. The PR worktree was clean after the run.

This is a real provider run of the exact PR head, not a result for later revisions, other hosts, or the separate no-JAVA_HOME problem #8171. Correction to my earlier note: inline_evidence: true can still describe retrieval and checking of complete Evidence inline, as the PR explains; it should not be read as claiming that the two comparison inputs remain inline.

@morluto commented on GitHub (Oct 31, 2026): Real-provider validation of the actual open [PR #8258](https://github.com/morluto/rea/pull/8258) head `2bf92eb91964d136256116badbf50001dfabedf0`: on macOS arm64, Node 24.22.1, Ghidra 12.1.4 and JDK 21, I ran `npm run verify:ghidra` with explicit `GHIDRA_INSTALL_DIR` and `JAVA_HOME`. The build completed and the host-native verifier exited 0 with `ok: true`, `cleanup: complete`, and no remaining owned descendants in its reported final process lineage. Its debug, stripped, type-layout and jump-table fixtures ran, including the comparison and downstream boundary assertions. The PR worktree was clean after the run. This is a real provider run of the exact PR head, not a result for later revisions, other hosts, or the separate no-`JAVA_HOME` problem #8171. Correction to my earlier note: `inline_evidence: true` can still describe retrieval and checking of complete Evidence inline, as the PR explains; it should not be read as claiming that the two comparison **inputs** remain inline.

bsakaguchi commented

2026-11-01 21:11:18 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Retested on REA a989c0e458c91af177e097abd7be0fd021b0401d, macOS arm64, Node 24.22.1, Ghidra 12.1.4 and JDK 21.0.12.1. With GHIDRA_INSTALL_DIR and a valid JAVA_HOME, npm run verify:ghidra gets past startup and again fails in verifyNativeValueAdapters at the compare_functions call: the default 1,024-element transport allowance rejects the two inline function dossiers before validation or execution. The lane did not finish; later fixture coverage and complete cleanup are not established by this run. PR #8258 remains open.

As a separate control, the current verify:kuna lane passed using the supplied Kuna 1.986 release and its generated symbolized and stripped fixtures; its report says cleanup completed. This confirms only that lane's selected workflows, not the missing Ghidra coverage or all provider features.

@morluto commented on GitHub (Oct 31, 2026): Retested on REA `a989c0e458c91af177e097abd7be0fd021b0401d`, macOS arm64, Node 24.22.1, Ghidra 12.1.4 and JDK 21.0.12.1. With `GHIDRA_INSTALL_DIR` and a valid `JAVA_HOME`, `npm run verify:ghidra` gets past startup and again fails in `verifyNativeValueAdapters` at the `compare_functions` call: the default 1,024-element transport allowance rejects the two inline function dossiers before validation or execution. The lane did not finish; later fixture coverage and complete cleanup are not established by this run. PR #8258 remains open. As a separate control, the current `verify:kuna` lane passed using the supplied Kuna 1.986 release and its generated symbolized and stripped fixtures; its report says cleanup completed. This confirms only that lane's selected workflows, not the missing Ghidra coverage or all provider features.

bsakaguchi commented

2026-11-01 21:11:18 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Current-base real-provider check: I applied exact PR head 2bf92eb91964d136256116badbf50001dfabedf0 as an uncommitted cherry-pick onto REA main 60149282fcfc05ac32fbc94434c107710120da6f in a detached worktree. The two touched files match the PR head exactly. With Node 24.22.1, Ghidra 12.1.4 and an explicit JDK 21 JAVA_HOME on macOS arm64, npm run verify:ghidra passed (ok:true, host-native): debug, stripped, type-layout and jump-table fixtures; 433 successful and 52 rejected boundary calls; report cleanup:complete and verified empty descendant list. This is the local combined tree, not a hosted CI result or a claim that the separate unset-JAVA_HOME issue #8171 is fixed. No target fixture was executed.

Paired control: unmodified main 60149282fcfc05ac32fbc94434c107710120da6f with the same explicit JDK and Ghidra installation exited 1 at native-value-e2e.mjs:266: compare_functions arguments exceeded the default 1,024-element limit before schema validation or execution. The full lane therefore did not complete on that baseline. This confirms the comparison-stage contrast on the same host; it does not establish cleanup completion for the failing run.

@morluto commented on GitHub (Oct 31, 2026): Current-base real-provider check: I applied exact PR head `2bf92eb91964d136256116badbf50001dfabedf0` as an uncommitted cherry-pick onto REA main `60149282fcfc05ac32fbc94434c107710120da6f` in a detached worktree. The two touched files match the PR head exactly. With Node 24.22.1, Ghidra 12.1.4 and an explicit JDK 21 `JAVA_HOME` on macOS arm64, `npm run verify:ghidra` passed (`ok:true`, host-native): debug, stripped, type-layout and jump-table fixtures; 433 successful and 52 rejected boundary calls; report `cleanup:complete` and verified empty descendant list. This is the local combined tree, not a hosted CI result or a claim that the separate unset-`JAVA_HOME` issue #8171 is fixed. No target fixture was executed. Paired control: unmodified main `60149282fcfc05ac32fbc94434c107710120da6f` with the same explicit JDK and Ghidra installation exited 1 at `native-value-e2e.mjs:266`: `compare_functions` arguments exceeded the default 1,024-element limit before schema validation or execution. The full lane therefore did not complete on that baseline. This confirms the comparison-stage contrast on the same host; it does not establish cleanup completion for the failing run.

bsakaguchi closed this issue

2026-11-03 07:17:00 +00:00

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

No description provided.

Rows
Columns