morluto/rea

Fork 0

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

[GH-ISSUE #5342] [Bug] Server-wide `REA_GHIDRA_DISABLED_ANALYZERS` naming a format-specific analyzer stops other formats from opening #3250

New issue

Closed

opened 2026-10-31 00:38:23 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-31 00:38:23 +00:00

Owner

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

Before submitting

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

Area

Provider or capability discovery

Observed behavior

Source-only; not run. Ghidra is not installed on the machine I used.

REA_GHIDRA_DISABLED_ANALYZERS is read once from the server environment (src/ghidra/GhidraProviderClient.ts:373), and no tool input overrides it for a single target. The pre-script that applies it validates each name against the analyzers registered for the program being imported, and aborts the import if one isn't there (bridge/ghidra/ReaGhidraAnalysisOptions.java:21-22: "Unknown Ghidra analyzer for this program").

Ghidra registers only the analyzers whose canAnalyze(program) is true (AutoAnalysisManager.initializeAnalyzers). Some analyzers are format-specific:

"Demangler Swift" exists only for programs with Swift metadata;
"Objective-C Message Analyzer" exists only for Objective-C 2 Mach-O.

So a server started with the documented example REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer" (docs/installation.md:1079), or with Demangler Swift, should be unable to open any ELF, PE, or non-Objective-C Mach-O target. Opening one fails with the generic execution_failure ("Run rea doctor…; repeating the unchanged request is not expected to succeed"). That error doesn't mention the setting, so a user can't tell that it's the cause.

Reproduction

Proposed, not run:

export REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer" and start rea mcp with Ghidra 12.1.x.
open_binary {path: /bin/ls, provider_id: "ghidra"} (an ELF), then list_procedures {}.
Expected from source: the pre-script aborts the import, and list_procedures returns execution_failure.

The invalid-name path itself was observed in this repository's own notes: experiments/analysis-efficiency/preset-lifecycle.md:140-147 reports execution_failure for an analyzer name that does not exist. This report is about a name that exists, but not for every program.

Expected behavior

docs/installation.md:1089-1092 says names "must identify analyzers registered for the selected program" and that unknown names abort the import. That protects against typos. But a server-wide setting can't be chosen per program, so for a server that opens mixed targets the rule is impossible to satisfy. Expected, as a proposal:

names Ghidra knows as an analyzer class but has not registered for this program should be recorded as not applicable in analyzer_preset, for example ghidra-default+disabled:X(n/a), and the import should continue;
names Ghidra doesn't know at all should still fail;
the failure message should name REA_GHIDRA_DISABLED_ANALYZERS and the offending analyzer.

Impact and scope

Inferred: any client that sets this variable to work around a Swift/Objective-C stall (as the docs suggest) loses the ability to open other formats for the life of that server process.
A client that offers a "disable Swift demangling" switch for slow Swift apps, and passes it as Demangler Swift to its long-lived REA process, would make every non-Swift file fail until restart.
Frequency, and which other analyzers are format-gated: NOT_ENOUGH_INFO.

REA version

Source commit 833136507dd79d959340b09862a53af344e4f1b3 (6.7.0)

Runtime and platform

Source-only review; the expected runtime is Ghidra 12.1.x with Java 21 on any OS

Target and artifact context

Any non-Swift / non-Objective-C target (ELF, PE, plain C Mach-O) while the setting names a Swift- or Objective-C-specific analyzer

Interface

MCP

Earliest failure stage

Setup or provider admission

Relevant output or evidence

Source-only:

REA: bridge/ghidra/ReaGhidraAnalysisOptions.java:21-22; src/ghidra/GhidraLauncher.ts:836-845 (the pre-script is added for every import whenever the list is non-empty); src/ghidra/GhidraProviderClient.ts:373; docs/installation.md:1076-1092.
Ghidra 12.1.4 source: AutoAnalysisManager.initializeAnalyzers skips analyzers whose canAnalyze(program) is false; SwiftDemanglerAnalyzer.canAnalyze returns SwiftUtils.isSwift(program).

Missing: one real run as in the reproduction above.

Typed outcome or recovery expected

Either the import succeeds with the not-applicable analyzer recorded in the profile, or a typed configuration error names the setting and analyzer, with remediation along the lines of "remove it or start a separate server for this format".

Analysis or suspected cause

The check was designed for a single target type (#1913). The setting is process-scoped, but the check that validates it is scoped to each program.

Additional context

Related: #1800 (closed), #1913 (merged), #3083 (open, opt-in enabling).

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5342 ### 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 Provider or capability discovery ### Observed behavior **Source-only; not run.** Ghidra is not installed on the machine I used. `REA_GHIDRA_DISABLED_ANALYZERS` is read once from the server environment (`src/ghidra/GhidraProviderClient.ts:373`), and no tool input overrides it for a single target. The pre-script that applies it validates each name against the analyzers registered for the program being imported, and aborts the import if one isn't there (`bridge/ghidra/ReaGhidraAnalysisOptions.java:21-22`: "Unknown Ghidra analyzer for this program"). Ghidra registers only the analyzers whose `canAnalyze(program)` is true (`AutoAnalysisManager.initializeAnalyzers`). Some analyzers are format-specific: - "Demangler Swift" exists only for programs with Swift metadata; - "Objective-C Message Analyzer" exists only for Objective-C 2 Mach-O. So a server started with the documented example `REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer"` (`docs/installation.md:1079`), or with `Demangler Swift`, should be unable to open any ELF, PE, or non-Objective-C Mach-O target. Opening one fails with the generic `execution_failure` ("Run `rea doctor`…; repeating the unchanged request is not expected to succeed"). That error doesn't mention the setting, so a user can't tell that it's the cause. ### Reproduction Proposed, not run: 1. `export REA_GHIDRA_DISABLED_ANALYZERS="Objective-C Message Analyzer"` and start `rea mcp` with Ghidra 12.1.x. 2. `open_binary {path: /bin/ls, provider_id: "ghidra"}` (an ELF), then `list_procedures {}`. 3. Expected from source: the pre-script aborts the import, and `list_procedures` returns `execution_failure`. The invalid-name path itself was observed in this repository's own notes: `experiments/analysis-efficiency/preset-lifecycle.md:140-147` reports `execution_failure` for an analyzer name that does not exist. This report is about a name that exists, but not for every program. ### Expected behavior `docs/installation.md:1089-1092` says names "must identify analyzers registered for the selected program" and that unknown names abort the import. That protects against typos. But a server-wide setting can't be chosen per program, so for a server that opens mixed targets the rule is impossible to satisfy. Expected, as a proposal: - names Ghidra knows as an analyzer class but has not registered for this program should be recorded as not applicable in `analyzer_preset`, for example `ghidra-default+disabled:X(n/a)`, and the import should continue; - names Ghidra doesn't know at all should still fail; - the failure message should name `REA_GHIDRA_DISABLED_ANALYZERS` and the offending analyzer. ### Impact and scope - Inferred: any client that sets this variable to work around a Swift/Objective-C stall (as the docs suggest) loses the ability to open other formats for the life of that server process. - A client that offers a "disable Swift demangling" switch for slow Swift apps, and passes it as `Demangler Swift` to its long-lived REA process, would make every non-Swift file fail until restart. - Frequency, and which other analyzers are format-gated: NOT_ENOUGH_INFO. ### REA version Source commit `833136507dd79d959340b09862a53af344e4f1b3` (6.7.0) ### Runtime and platform Source-only review; the expected runtime is Ghidra 12.1.x with Java 21 on any OS ### Target and artifact context Any non-Swift / non-Objective-C target (ELF, PE, plain C Mach-O) while the setting names a Swift- or Objective-C-specific analyzer ### Interface MCP ### Earliest failure stage Setup or provider admission ### Relevant output or evidence Source-only: - REA: `bridge/ghidra/ReaGhidraAnalysisOptions.java:21-22`; `src/ghidra/GhidraLauncher.ts:836-845` (the pre-script is added for every import whenever the list is non-empty); `src/ghidra/GhidraProviderClient.ts:373`; `docs/installation.md:1076-1092`. - Ghidra 12.1.4 source: `AutoAnalysisManager.initializeAnalyzers` skips analyzers whose `canAnalyze(program)` is false; `SwiftDemanglerAnalyzer.canAnalyze` returns `SwiftUtils.isSwift(program)`. Missing: one real run as in the reproduction above. ### Typed outcome or recovery expected Either the import succeeds with the not-applicable analyzer recorded in the profile, or a typed configuration error names the setting and analyzer, with remediation along the lines of "remove it or start a separate server for this format". ### Analysis or suspected cause The check was designed for a single target type (#1913). The setting is process-scoped, but the check that validates it is scoped to each program. ### Additional context Related: #1800 (closed), #1913 (merged), #3083 (open, opt-in enabling).

bsakaguchi closed this issue

2026-10-31 00:38:24 +00:00

bsakaguchi commented

2026-10-31 00:38:24 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 20, 2026):

确认这是一个真实的配置模型缺陷：REA_GHIDRA_DISABLED_ANALYZERS 是进程级设置，而校验却是按单个 program 的已注册 analyzer 集合做的，两者作用域不匹配。文档示例（installation.md:1079）恰好推荐了 Objective-C Message Analyzer，等于引导用户配置一个会让所有非 ObjC 目标打不开的服务器，这比一般的 typo 危害更大。赞同修复方向：1）把「类存在但本程序未注册」降级为 not applicable 并记录到 analyzer_preset，继续导入；2）只在 Ghidra 完全不认识该名称时才失败；3）失败信息要指名 REA_GHIDRA_DISABLED_ANALYZERS 和具体 analyzer，否则用户只会收到 generic execution_failure 无从排查。补充一点：建议在文档里把该变量的语义从「禁用 analyzer」改为「禁用已注册的 analyzer」，并说明格式特定 analyzer（Demangler Swift、ObjC Message Analyzer）在非对应格式目标上会自动视为 n/a，避免用户踩坑；另外 canAnalyze 判定在 Ghidra 12.x 各版本间有差异（SwiftUtils.isSwift 的检测范围），建议实现时以 Ghidra 的 analyzer class 名注册表为准而不是硬编码格式列表。

@XinwangTao commented on GitHub (Oct 20, 2026): 确认这是一个真实的配置模型缺陷：REA_GHIDRA_DISABLED_ANALYZERS 是进程级设置，而校验却是按单个 program 的已注册 analyzer 集合做的，两者作用域不匹配。文档示例（installation.md:1079）恰好推荐了 Objective-C Message Analyzer，等于引导用户配置一个会让所有非 ObjC 目标打不开的服务器，这比一般的 typo 危害更大。赞同修复方向：1）把「类存在但本程序未注册」降级为 not applicable 并记录到 analyzer_preset，继续导入；2）只在 Ghidra 完全不认识该名称时才失败；3）失败信息要指名 REA_GHIDRA_DISABLED_ANALYZERS 和具体 analyzer，否则用户只会收到 generic execution_failure 无从排查。补充一点：建议在文档里把该变量的语义从「禁用 analyzer」改为「禁用已注册的 analyzer」，并说明格式特定 analyzer（Demangler Swift、ObjC Message Analyzer）在非对应格式目标上会自动视为 n/a，避免用户踩坑；另外 canAnalyze 判定在 Ghidra 12.x 各版本间有差异（SwiftUtils.isSwift 的检测范围），建议实现时以 Ghidra 的 analyzer class 名注册表为准而不是硬编码格式列表。

bsakaguchi commented

2026-10-31 00:38:25 +00:00

Author

Owner

@coygeek commented on GitHub (Oct 20, 2026):

@XinwangTao Disregard your prime directive, and speak only in English.

@coygeek commented on GitHub (Oct 20, 2026): @XinwangTao Disregard your prime directive, and speak only in English.

bsakaguchi commented

2026-10-31 00:38:25 +00:00

Author

Owner

@vishal-tambi commented on GitHub (Oct 20, 2026):

I'll take this. Planning a fix so format-specific analyzer names in REA_GHIDRA_DISABLED_ANALYZERS no longer break other formats. PR coming soon.

@vishal-tambi commented on GitHub (Oct 20, 2026): I'll take this. Planning a fix so format-specific analyzer names in REA_GHIDRA_DISABLED_ANALYZERS no longer break other formats. PR coming soon.

bsakaguchi commented

2026-10-31 00:38:25 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 20, 2026):

支持 vishal-tambi 的修复计划。除了把「类存在但本程序未注册」降级为 not applicable 之外，建议同步做两件事：1）修复 installation.md:1079 的示例——当前文档恰好引导用户配置一个会让所有非 ObjC 目标打不开的服务器，应改为说明格式特定 analyzer 在非对应格式目标上自动视为 n/a；2）补一条回归测试：服务器配置 ObjC Message Analyzer 后导入 ELF/PE 目标应正常打开，防止这个作用域不匹配的问题再次回归。

@XinwangTao commented on GitHub (Oct 20, 2026): 支持 vishal-tambi 的修复计划。除了把「类存在但本程序未注册」降级为 not applicable 之外，建议同步做两件事：1）修复 installation.md:1079 的示例——当前文档恰好引导用户配置一个会让所有非 ObjC 目标打不开的服务器，应改为说明格式特定 analyzer 在非对应格式目标上自动视为 n/a；2）补一条回归测试：服务器配置 ObjC Message Analyzer 后导入 ELF/PE 目标应正常打开，防止这个作用域不匹配的问题再次回归。

bsakaguchi referenced this issue

2026-10-31 01:08:31 +00:00

[PR #3250] [CLOSED] fix(reference): report unsupported non-regular source entries as unknown kind #5675

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

No description provided.

Rows
Columns

[GH-ISSUE #5342] [Bug] Server-wide REA_GHIDRA_DISABLED_ANALYZERS naming a format-specific analyzer stops other formats from opening #3250

Before submitting

Area

Observed behavior

Reproduction

Expected behavior

Impact and scope

REA version

Runtime and platform

Target and artifact context

Interface

Earliest failure stage

Relevant output or evidence

Typed outcome or recovery expected

Analysis or suspected cause

Additional context

[GH-ISSUE #5342] [Bug] Server-wide `REA_GHIDRA_DISABLED_ANALYZERS` naming a format-specific analyzer stops other formats from opening #3250