morluto/rea

Fork 0

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

[GH-ISSUE #5329] [Bug] pwndbg debugger-context output-limit message reads "exceeds64 MiB" #3238

New issue

Closed

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

bsakaguchi commented

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

Owner

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

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

When the complete recorded-crash debugger mapping context (inspect-recorded-crash --debugger-context, MCP include_debugger_context: true) exceeds the 64 MiB reply budget, the pwndbg bridge refuses it with the message Complete debugger context exceeds64 MiB reply budget. The words "exceeds" and "64" are joined. The refusal and its limit are otherwise correct. I observed this by running the production bridge code against the repository's fake-GDB test fixture; I did not run a native Linux GDB/pwndbg session through the CLI or MCP.

Reproduction

From the repository root (no build needed), save this script outside the checkout and run it with python3:

import importlib.util, json, types
from unittest.mock import patch
spec = importlib.util.spec_from_file_location("t", "bridge/pwndbg/test_core_context.py")
t = importlib.util.module_from_spec(spec); spec.loader.exec_module(t)
case = t.CoreContextTests()
control, _, _, _ = case.inspect()
print("control ok:", control["ok"])
real = types.SimpleNamespace
def big(**v):
    if "objfile" in v:
        v["objfile"] = "/" + "a" * (64 * 1024 * 1024)
    return real(**v)
with patch.object(t.types, "SimpleNamespace", big):
    failure, _, _, _ = case.inspect()
print(json.dumps(failure))

It reuses the existing fixture in bridge/pwndbg/test_core_context.py, first at ordinary size, then with one mapping name enlarged past 64 MiB so the real main() serializer takes its output-limit branch. Reproduced on 2 of 2 runs. The native trigger (a supported Linux x64 core whose mapping context exceeds 64 MiB) was not run.

Expected behavior

docs/recorded-crashes.md ("Bounds and verification") lists a "64 MiB decoder reply" limit and says "Complete oversized results fail explicitly"; bridge/pwndbg/core_context.py:8 sets the same 64 MiB OUTPUT_BYTES for this bridge. The refusal should stay the same, with its message separating "exceeds" from "64 MiB", as the sibling pwntools refusal in bridge/pwntools/decoder_runtime.py:55 does: Complete artifact result exceeds the 64 MiB reply budget.

Impact and scope

Cosmetic only. The bridge reply keeps reason: "output-limit", the public error stays unreadable_output, and the 64 MiB limit and refusal of oversized data are unchanged. It appears only when the complete debugger context exceeds 64 MiB; how often real cores reach that is unknown.

REA version

main at 5fa4defcbc (executed). The rea-agents-6.7.0 tag contains the identical literal (source checked, release not executed).

Runtime and platform

Python 3.9.6, macOS arm64, source checkout; no real GDB or pwndbg used.

Target and artifact context

Recorded-crash debugger mapping context; reproduced with the repository's fake-GDB fixture, not a real core.

Interface

Python bridge

Earliest failure stage

Transport or result projection

Relevant output or evidence

Script output:

control ok: True
{"ok": false, "reason": "output-limit", "message": "Complete debugger context exceeds64 MiB reply budget."}

Source: bridge/pwndbg/core_context.py:96-98 writes the joined literal when the encoded reply exceeds OUTPUT_BYTES. From source reading (not executed end to end), src/native/pwndbg/PwndbgCoreContext.ts:238-241 raises this message as an AnalysisOutputError, and src/domain/analysisErrorProjection.ts:223 and :304-307 publish it as unreadable_output with this message as details.reason. Changing only that literal to exceeds the 64 MiB made the script print the corrected message.

Typed outcome or recovery expected

The same unreadable_output error (bridge reason output-limit), with the message separating "exceeds" from "64 MiB".

Analysis or suspected cause

Missing space in the string literal at bridge/pwndbg/core_context.py:98.

Additional context

Searched open and closed issues and PRs for exceeds64, "Complete debugger context", pwndbg, output-limit and reply-budget wording; related recorded-crash reports #4914 and #4942 concern different defects.

Separate observation, for the maintainer's judgment only: the version-mismatch message at bridge/pwndbg/core_context.py:36 reads Expected unchanged pwndbg2026.09.15; ..., while the docs write pwndbg 2026.09.15. The original capability PR #1054 uses the same joined notation, so it may be deliberate.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5329 ### 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 When the complete recorded-crash debugger mapping context (`inspect-recorded-crash --debugger-context`, MCP `include_debugger_context: true`) exceeds the 64 MiB reply budget, the pwndbg bridge refuses it with the message `Complete debugger context exceeds64 MiB reply budget.` The words "exceeds" and "64" are joined. The refusal and its limit are otherwise correct. I observed this by running the production bridge code against the repository's fake-GDB test fixture; I did not run a native Linux GDB/pwndbg session through the CLI or MCP. ### Reproduction From the repository root (no build needed), save this script outside the checkout and run it with `python3`: ```python import importlib.util, json, types from unittest.mock import patch spec = importlib.util.spec_from_file_location("t", "bridge/pwndbg/test_core_context.py") t = importlib.util.module_from_spec(spec); spec.loader.exec_module(t) case = t.CoreContextTests() control, _, _, _ = case.inspect() print("control ok:", control["ok"]) real = types.SimpleNamespace def big(**v): if "objfile" in v: v["objfile"] = "/" + "a" * (64 * 1024 * 1024) return real(**v) with patch.object(t.types, "SimpleNamespace", big): failure, _, _, _ = case.inspect() print(json.dumps(failure)) ``` It reuses the existing fixture in `bridge/pwndbg/test_core_context.py`, first at ordinary size, then with one mapping name enlarged past 64 MiB so the real `main()` serializer takes its output-limit branch. Reproduced on 2 of 2 runs. The native trigger (a supported Linux x64 core whose mapping context exceeds 64 MiB) was not run. ### Expected behavior `docs/recorded-crashes.md` ("Bounds and verification") lists a "64 MiB decoder reply" limit and says "Complete oversized results fail explicitly"; `bridge/pwndbg/core_context.py:8` sets the same 64 MiB `OUTPUT_BYTES` for this bridge. The refusal should stay the same, with its message separating "exceeds" from "64 MiB", as the sibling pwntools refusal in `bridge/pwntools/decoder_runtime.py:55` does: `Complete artifact result exceeds the 64 MiB reply budget.` ### Impact and scope Cosmetic only. The bridge reply keeps `reason: "output-limit"`, the public error stays `unreadable_output`, and the 64 MiB limit and refusal of oversized data are unchanged. It appears only when the complete debugger context exceeds 64 MiB; how often real cores reach that is unknown. ### REA version `main` at 5fa4defcbc0e55ef1ec84c888b918abe945303fe (executed). The `rea-agents-6.7.0` tag contains the identical literal (source checked, release not executed). ### Runtime and platform Python 3.9.6, macOS arm64, source checkout; no real GDB or pwndbg used. ### Target and artifact context Recorded-crash debugger mapping context; reproduced with the repository's fake-GDB fixture, not a real core. ### Interface Python bridge ### Earliest failure stage Transport or result projection ### Relevant output or evidence Script output: ```text control ok: True {"ok": false, "reason": "output-limit", "message": "Complete debugger context exceeds64 MiB reply budget."} ``` Source: `bridge/pwndbg/core_context.py:96-98` writes the joined literal when the encoded reply exceeds `OUTPUT_BYTES`. From source reading (not executed end to end), `src/native/pwndbg/PwndbgCoreContext.ts:238-241` raises this message as an `AnalysisOutputError`, and `src/domain/analysisErrorProjection.ts:223` and `:304-307` publish it as `unreadable_output` with this message as `details.reason`. Changing only that literal to `exceeds the 64 MiB` made the script print the corrected message. ### Typed outcome or recovery expected The same `unreadable_output` error (bridge reason `output-limit`), with the message separating "exceeds" from "64 MiB". ### Analysis or suspected cause Missing space in the string literal at `bridge/pwndbg/core_context.py:98`. ### Additional context Searched open and closed issues and PRs for `exceeds64`, "Complete debugger context", pwndbg, output-limit and reply-budget wording; related recorded-crash reports #4914 and #4942 concern different defects. Separate observation, for the maintainer's judgment only: the version-mismatch message at `bridge/pwndbg/core_context.py:36` reads `Expected unchanged pwndbg2026.09.15; ...`, while the docs write `pwndbg 2026.09.15`. The original capability PR #1054 uses the same joined notation, so it may be deliberate.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

I'd like to take this. I'll fix the message to read "exceeds the 64 MiB reply budget", matching the pwntools refusal, and add a test for the oversized branch. PR to follow.

@darshjoshi commented on GitHub (Oct 20, 2026): I'd like to take this. I'll fix the message to read "exceeds the 64 MiB reply budget", matching the pwntools refusal, and add a test for the oversized branch. PR to follow.

bsakaguchi commented

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

Author

Owner

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

确认这个缺空格是纯 cosmetic 但值得修——不过对用户而言它出现在拒绝消息里，读起来像「exceeds64 MiB」这个伪单位，确实影响可读性，和 pwntools 侧措辞保持一致是对的。支持 darshjoshi 认领的修复方向。一点提醒：报告里附带观察的 version-mismatch 消息（Expected unchanged pwndbg2026.09.15）与文档的带空格写法不一致，但 #1054 原始实现就是这个 joined 风格，很可能是故意的（版本字面量当 token 处理），建议 PR 里只核对不改，避免误伤。另外建议断言里顺带覆盖 reason: "output-limit" 字段保持不变，防止将来有人把拒绝语义一并改掉。

@XinwangTao commented on GitHub (Oct 20, 2026): 确认这个缺空格是纯 cosmetic 但值得修——不过对用户而言它出现在拒绝消息里，读起来像「exceeds64 MiB」这个伪单位，确实影响可读性，和 pwntools 侧措辞保持一致是对的。支持 darshjoshi 认领的修复方向。一点提醒：报告里附带观察的 version-mismatch 消息（Expected unchanged pwndbg2026.09.15）与文档的带空格写法不一致，但 #1054 原始实现就是这个 joined 风格，很可能是故意的（版本字面量当 token 处理），建议 PR 里只核对不改，避免误伤。另外建议断言里顺带覆盖 reason: "output-limit" 字段保持不变，防止将来有人把拒绝语义一并改掉。

bsakaguchi commented

2026-10-31 00:38:14 +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:14 +00:00

Author

Owner

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

#5372 已合并并自动关闭本 issue，文案修正（"exceeds the 64 MiB reply budget"）与 pwntools 措辞对齐，方向没问题。希望回归测试已覆盖 XinwangTao 提到的两点：reason: "output-limit" 字段保持不变，以及 version-mismatch 消息保持原样不被一并改写。

@XinwangTao commented on GitHub (Oct 20, 2026): #5372 已合并并自动关闭本 issue，文案修正（"exceeds the 64 MiB reply budget"）与 pwntools 措辞对齐，方向没问题。希望回归测试已覆盖 XinwangTao 提到的两点：reason: "output-limit" 字段保持不变，以及 version-mismatch 消息保持原样不被一并改写。

bsakaguchi referenced this issue

2026-10-31 00:44:00 +00:00

[GH-ISSUE #6213] [Bug] Capture fails when an initially absent observation root gains a non-directory ancestor #3782

bsakaguchi referenced this issue

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

[PR #3263] [CLOSED] test(process): cover cancellation during obstructed root lookup #5682

bsakaguchi referenced this issue

2026-11-01 21:46:24 +00:00

[PR #6264] [MERGED] fix(process): keep capture evidence when an admitted root's ancestor changes #7238