morluto/rea

Fork 0

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

[GH-ISSUE #4497] [Bug] Cutter discovery loses the loaded document path #1784

New issue

Closed

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

bsakaguchi commented

2026-10-16 21:10:14 +00:00

Owner

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

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

With an ELF loaded in official Linux Cutter 2.5.0 (Qt5), both CLI and stdio MCP discovery return current_file: null, document_generation: 0, and identity_status: "partial". A command on that same session returns ij.core.file equal to the loaded ELF path.

Reproduction

Start the official Cutter 2.5.0 Qt5 AppImage under Xvfb, with the shipped REA Python plugin in a private XDG profile, and open a controlled ELF (-A 0).
Run rea list-cutter-sessions --json and the MCP list_cutter_sessions tool.
Run rea cutter-command <session> 0 ij --json-output --json and MCP cutter_command with json: true on that session.

Observed in one completed clean-main workflow, and independently in the #3946 working-tree workflow. The ELF stayed unchanged and was not executed. Closing MCP preserved Cutter; stopping the fixture-owned GUI left a verified empty process lineage.

Expected behavior

Discovery should report the loaded document path from Cutter's owning API. Genuine absence or an unreadable value should remain explicitly unknown.

Impact and scope

The tested CLI/MCP session lacks document identity despite a loaded file. Source-derived consequence: document-generation tracking cannot observe path changes through a getter that always fails. Actual GUI document switching, older Cutter releases, and other operating systems were not tested.

REA version

Clean source 180ba03bfddd5916251e81e97a500b1ede7a9eea.

Runtime and platform

Linux x86_64; Node 24.18.0/npm 11.16.0; official Cutter 2.5.0-HEAD-a6f6ad7 Qt5, embedded Rizin 0.9.1. Qt6 plugin loading has a separate upstream issue (rizinorg/cutter#3659); this report uses the functioning Qt5 build.

Target and artifact context

Controlled ELF64, SHA-256 8f89b96d1dd56e1cd649dd5ed81b656de5429f9264bcc92e42ab2dd863d88b31.

Interface

Python bridge, observed through CLI and MCP.

Earliest failure stage

Capture or observation

Relevant output or evidence

Actual output, private paths replaced with a placeholder:

{"discovery_status":"sessions_found","session":{"current_file":null,"document_generation":0,"identity_status":"partial"}}

The same session's successful ij output includes:

{"core":{"file":"<owned-fixture>/fixture.elf"},"bin":{"bintype":"elf","bits":64}}

Analysis or suspected cause

Source-derived and native-probe refinement: _read_current_file calls currentlyOpenFile() and swallows its exception. The real Python binding exposes that member as a string, but it remains empty during the tested static analysis. Merely reading the property also failed a real-app candidate test.

In an independent, read-only plugin on the same owned Qt5 fixture, core.getConfig("file.path") exactly matched ij.core.file (including Unicode and #?), while core.currentlyOpenFile was "". Cutter v2.5.0's core implementation assigns the member when starting debugging, from that configuration value; it is not maintained as the ordinary current-file getter. The producer should read the current core configuration directly, preserving nonempty string values and explicit unknowns.

Fresh clean-main a6c6a76d37c729e17cccf2dd20fe8e8177d98b14 also reproduced null discovery with successful ELF metadata reads. The direct API probe used a separate private diagnostic plugin; this is distinct from the unmodified clean-main reproduction.

Additional context

Discovered during #4227; keep separate from #3946's discovery cancellation fix. Related #3330 concerns frame encoding, not document identity. Last known good version: NOT_ENOUGH_INFO.

Originally created by @N0zoM1z0 on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4497 ### 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 With an ELF loaded in official Linux Cutter 2.5.0 (Qt5), both CLI and stdio MCP discovery return `current_file: null`, `document_generation: 0`, and `identity_status: "partial"`. A command on that same session returns `ij.core.file` equal to the loaded ELF path. ### Reproduction 1. Start the official Cutter 2.5.0 Qt5 AppImage under Xvfb, with the shipped REA Python plugin in a private XDG profile, and open a controlled ELF (`-A 0`). 2. Run `rea list-cutter-sessions --json` and the MCP `list_cutter_sessions` tool. 3. Run `rea cutter-command <session> 0 ij --json-output --json` and MCP `cutter_command` with `json: true` on that session. Observed in one completed clean-main workflow, and independently in the #3946 working-tree workflow. The ELF stayed unchanged and was not executed. Closing MCP preserved Cutter; stopping the fixture-owned GUI left a verified empty process lineage. ### Expected behavior Discovery should report the loaded document path from Cutter's owning API. Genuine absence or an unreadable value should remain explicitly unknown. ### Impact and scope The tested CLI/MCP session lacks document identity despite a loaded file. Source-derived consequence: document-generation tracking cannot observe path changes through a getter that always fails. Actual GUI document switching, older Cutter releases, and other operating systems were not tested. ### REA version Clean source `180ba03bfddd5916251e81e97a500b1ede7a9eea`. ### Runtime and platform Linux x86_64; Node 24.18.0/npm 11.16.0; official Cutter `2.5.0-HEAD-a6f6ad7` Qt5, embedded Rizin 0.9.1. Qt6 plugin loading has a separate upstream issue (rizinorg/cutter#3659); this report uses the functioning Qt5 build. ### Target and artifact context Controlled ELF64, SHA-256 `8f89b96d1dd56e1cd649dd5ed81b656de5429f9264bcc92e42ab2dd863d88b31`. ### Interface Python bridge, observed through CLI and MCP. ### Earliest failure stage Capture or observation ### Relevant output or evidence Actual output, private paths replaced with a placeholder: ```json {"discovery_status":"sessions_found","session":{"current_file":null,"document_generation":0,"identity_status":"partial"}} ``` The same session's successful `ij` output includes: ```json {"core":{"file":"<owned-fixture>/fixture.elf"},"bin":{"bintype":"elf","bits":64}} ``` ### Analysis or suspected cause Source-derived and native-probe refinement: [`_read_current_file`](https://github.com/morluto/rea/blob/a6c6a76d37c729e17cccf2dd20fe8e8177d98b14/bridge/cutter/rea_bridge.py) calls `currentlyOpenFile()` and swallows its exception. The real Python binding exposes that member as a string, but it remains empty during the tested static analysis. Merely reading the property also failed a real-app candidate test. In an independent, read-only plugin on the same owned Qt5 fixture, `core.getConfig("file.path")` exactly matched `ij.core.file` (including Unicode and `#?`), while `core.currentlyOpenFile` was `""`. [Cutter v2.5.0's core implementation](https://github.com/rizinorg/cutter/blob/v2.5.0/src/core/Cutter.cpp#L2096) assigns the member when starting debugging, from that configuration value; it is not maintained as the ordinary current-file getter. The producer should read the current core configuration directly, preserving nonempty string values and explicit unknowns. Fresh clean-main `a6c6a76d37c729e17cccf2dd20fe8e8177d98b14` also reproduced null discovery with successful ELF metadata reads. The direct API probe used a separate private diagnostic plugin; this is distinct from the unmodified clean-main reproduction. ### Additional context Discovered during #4227; keep separate from #3946's discovery cancellation fix. Related #3330 concerns frame encoding, not document identity. Last known good version: `NOT_ENOUGH_INFO`.

bsakaguchi

2026-10-16 21:10:14 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi referenced this issue

2026-10-31 00:55:19 +00:00

[PR #1784] [MERGED] fix(apple): validate build-version tool records within cmdsize #4814

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

No description provided.

Rows
Columns