morluto/rea

Fork 0

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

[GH-ISSUE #8752] [Bug] Ambiguous Ghidra name lookup suggests schema repair #7536

New issue

Closed

opened 2026-11-03 09:20:09 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 09:20:09 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8752

Before submitting

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

Area

Native analysis or decompilation

Observed behavior

find_xrefs_to_name correctly refuses a valid name that identifies multiple addresses and lists the candidates, but its structured recovery says inspect_input_contract and tells the caller to repair the schema. The candidate-specific action is to select an address and use xrefs.

Reproduction

On REA main 9ebbe67e05af08b567e215340da993c08dae378f, Node 24.22.1, macOS arm64 and real Ghidra 12.1.4:

Build an unexecuted arm64 Mach-O from two C files, each defining a static volatile int shared_name, with a distinct used noinline function returning its address. Link both with a trivial main.
nm -nm reports two non-external _shared_name symbols, at 0x100004000 and 0x100004004 for this build.
Open it with Ghidra and call MCP find_xrefs_to_name({"name":"_shared_name"}). Both compact and full profiles return invalid_request with the two addresses and “Select an exact address” in details.issues, while top-level remediation says to inspect the schema and correct fields, with recovery.kind: inspect_input_contract.
In the same session xrefs at the two exact addresses succeeds and returns distinct reference sites, 0x1000003c4 and 0x1000003d0 respectively. Addresses are fixture-specific. Successful calls used fetched SDK tool definitions.

The fixture SHA-256 8987f6c8d6aa3f697636b43260410e56179f91a7d9ec7f19b3e809538853ba53 stayed unchanged; it was not executed.

Expected behavior

Retain ambiguity and both candidates, and offer candidate selection followed by an explicit-address xrefs call. Do not suggest schema repair for this valid input or select an address automatically. Preserve genuine malformed-input schema recovery.

Impact and scope

The current result prevents wrong first-match selection, but gives contradictory recovery instructions. This is one real Ghidra fixture and two MCP profiles; CLI and actual agent behavior were not tested.

REA version

9ebbe67e05af08b567e215340da993c08dae378f.

Runtime and platform

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

Target and artifact context

Source-owned unexecuted Mach-O with two same-named local data symbols; no mutation.

Interface

MCP.

Earliest failure stage

Name-resolution error projection.

Relevant output or evidence

details.issues[0].message lists 0x100004000, 0x100004004; recovery.kind is inspect_input_contract.

Typed outcome or recovery expected

Candidate-selection guidance with the original selector and distinct addresses, keeping invalid schema input separate.

Analysis or suspected cause

Source-derived: the shared XrefsAddressResolution produces an AnalysisInputError for ambiguity without specific recovery; the generic analysis-error projection defaults to schema inspection. Confirm other consumers and preserve their operation-specific semantics when fixing.

Additional context

Related closed #5908 fixed first-match selection. Related #8478 and #8396 cover Kuna selector recovery, not this Ghidra-backed shared name-resolution path. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8752 ### Before submitting - [x] I searched open and closed issues for a related report. - [x] I removed credentials, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `find_xrefs_to_name` correctly refuses a valid name that identifies multiple addresses and lists the candidates, but its structured recovery says `inspect_input_contract` and tells the caller to repair the schema. The candidate-specific action is to select an address and use `xrefs`. ### Reproduction On REA main `9ebbe67e05af08b567e215340da993c08dae378f`, Node 24.22.1, macOS arm64 and real Ghidra 12.1.4: 1. Build an unexecuted arm64 Mach-O from two C files, each defining a `static volatile int shared_name`, with a distinct used noinline function returning its address. Link both with a trivial `main`. 2. `nm -nm` reports two non-external `_shared_name` symbols, at `0x100004000` and `0x100004004` for this build. 3. Open it with Ghidra and call MCP `find_xrefs_to_name({"name":"_shared_name"})`. Both compact and full profiles return `invalid_request` with the two addresses and “Select an exact address” in `details.issues`, while top-level remediation says to inspect the schema and correct fields, with `recovery.kind: inspect_input_contract`. 4. In the same session `xrefs` at the two exact addresses succeeds and returns distinct reference sites, `0x1000003c4` and `0x1000003d0` respectively. Addresses are fixture-specific. Successful calls used fetched SDK tool definitions. The fixture SHA-256 `8987f6c8d6aa3f697636b43260410e56179f91a7d9ec7f19b3e809538853ba53` stayed unchanged; it was not executed. ### Expected behavior Retain ambiguity and both candidates, and offer candidate selection followed by an explicit-address `xrefs` call. Do not suggest schema repair for this valid input or select an address automatically. Preserve genuine malformed-input schema recovery. ### Impact and scope The current result prevents wrong first-match selection, but gives contradictory recovery instructions. This is one real Ghidra fixture and two MCP profiles; CLI and actual agent behavior were not tested. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f`. ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4 and JDK 21. ### Target and artifact context Source-owned unexecuted Mach-O with two same-named local data symbols; no mutation. ### Interface MCP. ### Earliest failure stage Name-resolution error projection. ### Relevant output or evidence `details.issues[0].message` lists `0x100004000, 0x100004004`; `recovery.kind` is `inspect_input_contract`. ### Typed outcome or recovery expected Candidate-selection guidance with the original selector and distinct addresses, keeping invalid schema input separate. ### Analysis or suspected cause Source-derived: the shared `XrefsAddressResolution` produces an `AnalysisInputError` for ambiguity without specific recovery; the generic analysis-error projection defaults to schema inspection. Confirm other consumers and preserve their operation-specific semantics when fixing. ### Additional context Related closed #5908 fixed first-match selection. Related #8478 and #8396 cover Kuna selector recovery, not this Ghidra-backed shared name-resolution path. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi closed this issue

2026-11-04 18:21:31 +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#7536

No description provided.

Rows
Columns