morluto/rea

Fork 0

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

[GH-ISSUE #8767] [Bug] Ghidra ambiguous function selection suggests schema repair #7537

New issue

Open

opened 2026-11-03 10:21:16 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 10:21:16 +00:00

Owner

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

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

A valid ambiguous procedure name is refused by Ghidra with both candidate entry addresses in details.issues, but analyze_function's top-level recovery tells the caller to inspect the input schema and correct fields. The selector conforms to the schema; the useful action is to choose a candidate address.

Reproduction

On REA 9ebbe67e plus the unrelated address-context changes from #8766 (2b9381e87), Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21:

Build an arm64 Mach-O from two C translation units, each with a used, noinline static function named shared_func and an exported wrapper; link a trivial main. nm -an lists _shared_func at 0x100000328 and 0x1000003a0 in this build.
Open the target through stdio MCP and call search_procedures with { "pattern": "shared_func" }: both candidates are returned.
Call analyze_function with { "procedure": "_shared_func" }. In compact and full output profiles, the call is invalid_request. Its details say Ghidra procedure name is ambiguous and list both addresses; its remediation says to read the schema and its recovery.kind is inspect_input_contract.
In the same session, analyze_function with either exact address succeeds and the resulting summary identifies that entry. The address values are fixture-specific.

The target was not executed and SHA-256 remained ae0f2a349b22332113ab60ab4c78024eb18153c76bdeefb01c4b1d89a26c0003. The comparison using Kuna 1.989 also refused the ambiguous name and returned both addresses, but its message and remediation instructed selecting an exact address without inspect_input_contract.

Expected behavior

Preserve the name, ambiguity, and candidate addresses, and guide explicit address selection without claiming the schema is malformed. Preserve actual input-format recovery and do not select a candidate automatically. The exact-address controls above demonstrate a working recovery for this fixture.

Impact and scope

The error avoids silently choosing the wrong function but gives contradictory recovery. This is a constructed fixture, one host and provider version; CLI and autonomous-agent behavior were not exercised. No prevalence estimate is available.

REA version

9ebbe67e with #8766 head 2b9381e87; the latter changes address context, not Ghidra procedure failure projection.

Runtime and platform

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

Target and artifact context

Source-owned, unexecuted arm64 Mach-O with two same-named local functions.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Ghidra's error includes details.issues[0].message: Ghidra procedure name is ambiguous: _shared_func; select an exact entry address from [0x100000328, 0x1000003a0] while the top-level recovery is inspect_input_contract.

Typed outcome or recovery expected

Contract-valid ambiguous lookup with candidate-selection remediation; no inferred uniqueness or coverage guarantee.

Analysis or suspected cause

Source-derived: GhidraProviderClient maps remote ambiguous failures through the generic AnalysisInputError path without distinguishing a schema-valid selector. The bridge supplies the candidate addresses in its message. This differs from #8752, whose producer is shared name-to-xrefs resolution, and from #8478, which covers Kuna procedure selectors.

Additional context

Related #8752 and #8478. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8767 ### 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 A valid ambiguous procedure name is refused by Ghidra with both candidate entry addresses in `details.issues`, but `analyze_function`'s top-level recovery tells the caller to inspect the input schema and correct fields. The selector conforms to the schema; the useful action is to choose a candidate address. ### Reproduction On REA `9ebbe67e` plus the unrelated address-context changes from #8766 (`2b9381e87`), Node 24.22.1, macOS arm64, Ghidra 12.1.4 and JDK 21: 1. Build an arm64 Mach-O from two C translation units, each with a used, noinline static function named `shared_func` and an exported wrapper; link a trivial `main`. `nm -an` lists `_shared_func` at `0x100000328` and `0x1000003a0` in this build. 2. Open the target through stdio MCP and call `search_procedures` with `{ "pattern": "shared_func" }`: both candidates are returned. 3. Call `analyze_function` with `{ "procedure": "_shared_func" }`. In compact and full output profiles, the call is `invalid_request`. Its details say `Ghidra procedure name is ambiguous` and list both addresses; its remediation says to read the schema and its `recovery.kind` is `inspect_input_contract`. 4. In the same session, `analyze_function` with either exact address succeeds and the resulting summary identifies that entry. The address values are fixture-specific. The target was not executed and SHA-256 remained `ae0f2a349b22332113ab60ab4c78024eb18153c76bdeefb01c4b1d89a26c0003`. The comparison using Kuna 1.989 also refused the ambiguous name and returned both addresses, but its message and remediation instructed selecting an exact address without `inspect_input_contract`. ### Expected behavior Preserve the name, ambiguity, and candidate addresses, and guide explicit address selection without claiming the schema is malformed. Preserve actual input-format recovery and do not select a candidate automatically. The exact-address controls above demonstrate a working recovery for this fixture. ### Impact and scope The error avoids silently choosing the wrong function but gives contradictory recovery. This is a constructed fixture, one host and provider version; CLI and autonomous-agent behavior were not exercised. No prevalence estimate is available. ### REA version `9ebbe67e` with #8766 head `2b9381e87`; the latter changes address context, not Ghidra procedure failure projection. ### Runtime and platform Node 24.22.1; macOS arm64; Ghidra 12.1.4 and JDK 21. ### Target and artifact context Source-owned, unexecuted arm64 Mach-O with two same-named local functions. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Ghidra's error includes `details.issues[0].message: Ghidra procedure name is ambiguous: _shared_func; select an exact entry address from [0x100000328, 0x1000003a0]` while the top-level recovery is `inspect_input_contract`. ### Typed outcome or recovery expected Contract-valid ambiguous lookup with candidate-selection remediation; no inferred uniqueness or coverage guarantee. ### Analysis or suspected cause Source-derived: `GhidraProviderClient` maps remote `ambiguous` failures through the generic `AnalysisInputError` path without distinguishing a schema-valid selector. The bridge supplies the candidate addresses in its message. This differs from #8752, whose producer is shared name-to-xrefs resolution, and from #8478, which covers Kuna procedure selectors. ### Additional context Related #8752 and #8478. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi referenced this issue

2026-11-05 01:48:04 +00:00

[PR #7449] fix(mcp): advertise absolute filesystem paths #7842

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

No description provided.

Rows
Columns