morluto/rea

Fork 0

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

[GH-ISSUE #8024] [Bug] After a Rizin debug session is stopped by its frame limit, later commands return a generic invalid-input error and status gives no reason #4662

New issue

Open

opened 2026-10-31 00:52:09 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues for a related report (rizin frame limit, rizin protocol error session, rizin_debug_command closed session, invalid_request session). Related but different: #5896 (closed, cleanup after an output or frame limit was blocked; cleanup now works in my test), #8023 (the GDB session's single-line limit).
I removed credentials, tokens, private paths, and sensitive target data.

Area

Debugging (Rizin debug sessions)

Observed behavior

In a persistent Rizin debug session, a command whose output is one NUL frame over 16 MiB stops the session, as documented. With a large enough REA_MCP_MAX_RESPONSE_BYTES, the command's Evidence says so: output_truncated: true, completion_status: "unknown" and the limitation "The Rizin command exceeded the 16777216 byte frame limit. ... The owned debugger session was stopped."

After that:

Every later rizin_debug_command on the same session_id returns invalid_request / invalid_input: "Analysis input is invalid. Check the arguments and try again." Its remediation says to read the input schema and "Do not repeat the unchanged call". There is no details field. The same error comes back for a session ID that never existed, so a caller can't tell a stopped session from a typo.
rizin_debug_session_status reports state: "closed", but no field says why or when it closed.
close_rizin_debug_session succeeds with target_state: "unknown", and the inferior and Rizin process are gone. That part works.

At the default REA_MCP_MAX_RESPONSE_BYTES (10 MiB), the caller never sees that limitation. The capped 16 MiB output makes a response of about 34 MB, because the output appears in both raw_result and normalized_result. The command therefore returns resource_constraint, which says "The operation completed ... The analysis result was not truncated." The next call is the first sign of trouble, and it reads as an argument error. At 64 MiB the response still didn't fit. I had to set 256 MiB to see the Evidence.

A command whose output stays under the frame limit but over the response budget (px 2500000, about 10.7 MB) also returns resource_constraint, but the session stays usable, so the two cases look the same to the caller until the next call.

Code reference: RizinDebugSessionManager.execute returns new AnalysisInputError("rizin_debug_command") when the session is missing, not ready, exited, has a protocolError, or is closing.

Reproduction

I used a self-written probe in a Linux x64 container (--network none, --cap-add SYS_PTRACE) on Ubuntu 24.04 with the Rizin 0.9.1 static release. I ran it on rea-agents@6.8.0 and on main at 45cc93596. The results were the same.

/* utf8.c */
#include <stdio.h>
unsigned char bad[] = { 'o', 'k', 0xff, 0 };
int big[4000000];
__attribute__((noinline)) void stop_here(void) { puts("probe"); }
int main(void) { for (int i = 0; i < 4000000; i++) big[i] = i; stop_here(); return 0; }

Build with gcc -g -O0 -o /p/utf8 utf8.c, then run over MCP:

start_rizin_debug_session {"path":"/p/utf8","inferior_tty":"/dev/pts/0"}
rizin_debug_command "db @ sym.stop_here"
rizin_debug_command "dc"
rizin_debug_command "px 4000000 @ obj.big"   -> resource_constraint at 10 MiB; Evidence with the frame-limit limitation at 256 MiB
rizin_debug_command "dr rip"                 -> invalid_request, no details
rizin_debug_session_status                   -> state "closed", no reason
close_rizin_debug_session                    -> target_state "unknown"

Expected behavior

A command on a session that REA stopped should return an error that says the session was stopped and why (for example the retained protocol error), with recovery pointing to close_rizin_debug_session and a new session. It shouldn't be an argument error that tells the caller to fix their input.
rizin_debug_session_status could carry that reason next to state: "closed".
When a resource_constraint hides a result that itself reports a stopped session or partial output, the error could say so, or at least not state that the result was not truncated.

Impact and scope

This affects persistent Rizin debug sessions over MCP when one command prints more than 16 MiB, for example px of a large buffer. The cleanup itself works. The issue is that at the default settings the caller gets a misleading error sequence. I didn't check the other session-stopping paths (total output cap, 4096-frame cap, command deadline). They take the same protocolError branch in execute, so they likely behave the same way.

Originally created by @Rinkia on GitHub (Oct 29, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8024 ### Before submitting - [x] I searched the open and closed issues for a related report (rizin frame limit, rizin protocol error session, rizin_debug_command closed session, invalid_request session). Related but different: #5896 (closed, cleanup after an output or frame limit was blocked; cleanup now works in my test), #8023 (the GDB session's single-line limit). - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Debugging (Rizin debug sessions) ### Observed behavior In a persistent Rizin debug session, a command whose output is one NUL frame over 16 MiB stops the session, as documented. With a large enough `REA_MCP_MAX_RESPONSE_BYTES`, the command's Evidence says so: `output_truncated: true`, `completion_status: "unknown"` and the limitation "The Rizin command exceeded the 16777216 byte frame limit. ... The owned debugger session was stopped." After that: - Every later `rizin_debug_command` on the same `session_id` returns `invalid_request` / `invalid_input`: "Analysis input is invalid. Check the arguments and try again." Its remediation says to read the input schema and "Do not repeat the unchanged call". There is no `details` field. The same error comes back for a session ID that never existed, so a caller can't tell a stopped session from a typo. - `rizin_debug_session_status` reports `state: "closed"`, but no field says why or when it closed. - `close_rizin_debug_session` succeeds with `target_state: "unknown"`, and the inferior and Rizin process are gone. That part works. At the default `REA_MCP_MAX_RESPONSE_BYTES` (10 MiB), the caller never sees that limitation. The capped 16 MiB output makes a response of about 34 MB, because the output appears in both `raw_result` and `normalized_result`. The command therefore returns `resource_constraint`, which says "The operation completed ... The analysis result was not truncated." The next call is the first sign of trouble, and it reads as an argument error. At 64 MiB the response still didn't fit. I had to set 256 MiB to see the Evidence. A command whose output stays under the frame limit but over the response budget (`px 2500000`, about 10.7 MB) also returns `resource_constraint`, but the session stays usable, so the two cases look the same to the caller until the next call. Code reference: `RizinDebugSessionManager.execute` returns `new AnalysisInputError("rizin_debug_command")` when the session is missing, not ready, exited, has a `protocolError`, or is closing. ### Reproduction I used a self-written probe in a Linux x64 container (`--network none`, `--cap-add SYS_PTRACE`) on Ubuntu 24.04 with the Rizin 0.9.1 static release. I ran it on `rea-agents@6.8.0` and on `main` at `45cc93596`. The results were the same. ```c /* utf8.c */ #include <stdio.h> unsigned char bad[] = { 'o', 'k', 0xff, 0 }; int big[4000000]; __attribute__((noinline)) void stop_here(void) { puts("probe"); } int main(void) { for (int i = 0; i < 4000000; i++) big[i] = i; stop_here(); return 0; } ``` Build with `gcc -g -O0 -o /p/utf8 utf8.c`, then run over MCP: ``` start_rizin_debug_session {"path":"/p/utf8","inferior_tty":"/dev/pts/0"} rizin_debug_command "db @ sym.stop_here" rizin_debug_command "dc" rizin_debug_command "px 4000000 @ obj.big" -> resource_constraint at 10 MiB; Evidence with the frame-limit limitation at 256 MiB rizin_debug_command "dr rip" -> invalid_request, no details rizin_debug_session_status -> state "closed", no reason close_rizin_debug_session -> target_state "unknown" ``` ### Expected behavior - A command on a session that REA stopped should return an error that says the session was stopped and why (for example the retained protocol error), with recovery pointing to `close_rizin_debug_session` and a new session. It shouldn't be an argument error that tells the caller to fix their input. - `rizin_debug_session_status` could carry that reason next to `state: "closed"`. - When a `resource_constraint` hides a result that itself reports a stopped session or partial output, the error could say so, or at least not state that the result was not truncated. ### Impact and scope This affects persistent Rizin debug sessions over MCP when one command prints more than 16 MiB, for example `px` of a large buffer. The cleanup itself works. The issue is that at the default settings the caller gets a misleading error sequence. I didn't check the other session-stopping paths (total output cap, 4096-frame cap, command deadline). They take the same `protocolError` branch in `execute`, so they likely behave the same way.

bsakaguchi commented

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

Author

Owner

@jy9y4wds8z-alt commented on GitHub (Oct 29, 2026):

I am trying to find out who is the administrator or the organization that has control over this account and if I can find out what exactly is the issue that I have been trying to find out about and what I should be doing to help you resolve this issue so I can make sure that I can help with my business I am trying to get started

@jy9y4wds8z-alt commented on GitHub (Oct 29, 2026): I am trying to find out who is the administrator or the organization that has control over this account and if I can find out what exactly is the issue that I have been trying to find out about and what I should be doing to help you resolve this issue so I can make sure that I can help with my business I am trying to get started

bsakaguchi commented

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

Author

Owner

@jy9y4wds8z-alt commented on GitHub (Oct 29, 2026):

And I just want to make sure that you know that I don't have a employer or any other organization that has contacted me about this and I have not received any information by mail from a court decision that I was not aware of except that I have received two different medical data breaches and I have to start the identity monitoring service that is being provided for two years

@jy9y4wds8z-alt commented on GitHub (Oct 29, 2026): And I just want to make sure that you know that I don't have a employer or any other organization that has contacted me about this and I have not received any information by mail from a court decision that I was not aware of except that I have received two different medical data breaches and I have to start the identity monitoring service that is being provided for two years

bsakaguchi referenced this issue

2026-11-01 21:10:58 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

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

No description provided.

Rows
Columns