morluto/rea

Fork 0

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

[GH-ISSUE #5087] [Bug] EVM inspection reports a fixed 3 GiB address-space limit after selecting a tighter inherited limit #3124

New issue

Closed

opened 2026-10-31 00:36:55 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

SOURCE-ONLY; no public CLI/MCP or worker runtime reproduction was performed.

On the successful inspection path, the first limitation reports the selected address_space_bytes, while the last limitation always describes a 3 GiB virtual address-space limit. A valid inherited 2 GiB soft limit selects 2147483648 bytes, so the same report would describe both 2 GiB configured address space and a fixed 3 GiB limit. This follows from the actual production path, not an observed response.

Reproduction

Static verification actually performed on the source revision below:

Follow the CLI registration into the shared service and production provider: CLI entry, composition, and service.
The provider requires Linux x64, usable absolute-path prlimit, and valid inherited limit rows. It reads the inherited limits and selects configured worker limits. These guards do not reject a valid 2 GiB inherited soft address-space limit: admission and selection.
Selection takes the minimum of the 3 GiB profile maximum and inherited finite soft/hard limits. Thus a 2147483648-byte soft limit with unlimited hard limit selects 2147483648: selection, maximum.
The selected value configures prlimit --as=…:. After successful reply and carrier validation, both the selected value and the fixed 3 GiB claim enter the report and execution limitations: launch, result construction.
The service preserves these limitations in caller-facing Evidence: Evidence assembly.

The existing verification script explicitly includes a 2 GiB inherited-limit scenario for CLI and MCP and checks the selected-value limitation. That script was read, not executed.

Expected behavior

Describe the selected configured address-space limit consistently, or label 3 GiB as the maximum profile ceiling. The resource contract explicitly retains tighter inherited limits and reports configured soft limits inline. The unconditional per-worker sentence does not identify its number as a ceiling.

Impact and scope

A wording inconsistency affects successful inspections on supported Linux x64 hosts with inherited address-space limits below 3 GiB. The selected configured value remains available in the first limitation. No incorrect enforcement, analysis output, process isolation or resource failure was established. NOT_ENOUGH_INFO: real-world frequency and whether consumers rely on the fixed sentence.

REA version

Current main source SHA 3537e58c1ab29309f06eabf50bc52adba9817a0c, package version 6.7.0. The relevant provider, selector, constants, documentation and verification script are unchanged from stable rea-agents-6.7.0 at 27dc42d10249f0410904a75c0997842eb03b931c. This is source comparison; no stable runtime reproduction is claimed.

Runtime and platform

Inspection host: Node v26.12.0, Darwin 27.0.0, arm64. The production provider requires Linux x64. NOT_ENOUGH_INFO: a successful runtime response under a tighter inherited limit; no provider was launched locally.

Target and artifact context

No target was loaded. The source scenario concerns a benign local flat EVM hex carrier and an inherited 2147483648-byte address-space soft limit. No chain, RPC, wallet or target execution is involved.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Executed source comparison:

git rev-parse HEAD
git diff rea-agents-6.7.0 HEAD -- src/evm/EvmoleInterfaceProvider.ts src/evm/EvmWorkerLimits.ts src/evm/EvmoleRelease.ts docs/evm-bytecode.md scripts/verify-evm-interface.mjs

Observed HEAD was 3537e58c1ab29309f06eabf50bc52adba9817a0c; the diff produced no output. Line-numbered source reads established the static path above. The relevant result construction is at provider lines 396–443: the selected configured limit is interpolated, while the later 3 GiB figure is a literal. No captured runtime limitations array is available.

Typed outcome or recovery expected

Retain successful inspection Evidence and its accurate configured-limit entry, with the worker description agreeing with that entry or explicitly identifying a maximum. No new error classification is required by this wording defect.

Analysis or suspected cause

Source-derived: the selected address-space value is available when the limitations array is built, but the later sentence embeds the profile maximum as fixed per-worker prose. Schema validation accepts both strings and Evidence assembly forwards them unchanged.

Additional context

The complete supplied open-and-closed issue snapshot was searched using address-space, configured-limit and EVM inspection terms. No report matching this trigger and expected correction was found. The verification is conclusive static tracing; Linux runtime behavior, frequency and downstream consumption remain unmeasured.

Originally created by @coygeek on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5087 ## 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 Evidence, artifacts, or reconstruction ## Observed behavior SOURCE-ONLY; no public CLI/MCP or worker runtime reproduction was performed. On the successful inspection path, the first limitation reports the selected `address_space_bytes`, while the last limitation always describes a 3 GiB virtual address-space limit. A valid inherited 2 GiB soft limit selects 2147483648 bytes, so the same report would describe both 2 GiB configured address space and a fixed 3 GiB limit. This follows from the actual production path, not an observed response. ## Reproduction Static verification actually performed on the source revision below: 1. Follow the CLI registration into the shared service and production provider: [CLI entry](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/cli/evmCommands.ts#L16-L40), [composition](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/composition/evm.ts#L8-L11), and [service](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/evm/EvmInterfaceService.ts#L60-L87). 2. The provider requires Linux x64, usable absolute-path `prlimit`, and valid inherited limit rows. It reads the inherited limits and selects configured worker limits. These guards do not reject a valid 2 GiB inherited soft address-space limit: [admission and selection](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleInterfaceProvider.ts#L197-L243). 3. Selection takes the minimum of the 3 GiB profile maximum and inherited finite soft/hard limits. Thus a 2147483648-byte soft limit with unlimited hard limit selects 2147483648: [selection](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmWorkerLimits.ts#L20-L48), [maximum](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleRelease.ts#L10-L16). 4. The selected value configures `prlimit --as=…:`. After successful reply and carrier validation, both the selected value and the fixed 3 GiB claim enter the report and execution limitations: [launch](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleInterfaceProvider.ts#L274-L291), [result construction](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/evm/EvmoleInterfaceProvider.ts#L378-L443). 5. The service preserves these limitations in caller-facing Evidence: [Evidence assembly](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/evm/EvmInterfaceEvidence.ts#L10-L17). The existing [verification script](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/scripts/verify-evm-interface.mjs#L333-L366) explicitly includes a 2 GiB inherited-limit scenario for CLI and MCP and checks the selected-value limitation. That script was read, not executed. ## Expected behavior Describe the selected configured address-space limit consistently, or label 3 GiB as the maximum profile ceiling. The [resource contract](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/docs/evm-bytecode.md#L105-L115) explicitly retains tighter inherited limits and reports configured soft limits inline. The unconditional per-worker sentence does not identify its number as a ceiling. ## Impact and scope A wording inconsistency affects successful inspections on supported Linux x64 hosts with inherited address-space limits below 3 GiB. The selected configured value remains available in the first limitation. No incorrect enforcement, analysis output, process isolation or resource failure was established. NOT_ENOUGH_INFO: real-world frequency and whether consumers rely on the fixed sentence. ## REA version Current main source SHA `3537e58c1ab29309f06eabf50bc52adba9817a0c`, package version 6.7.0. The relevant provider, selector, constants, documentation and verification script are unchanged from stable `rea-agents-6.7.0` at `27dc42d10249f0410904a75c0997842eb03b931c`. This is source comparison; no stable runtime reproduction is claimed. ## Runtime and platform Inspection host: Node v26.12.0, Darwin 27.0.0, arm64. The production provider requires Linux x64. NOT_ENOUGH_INFO: a successful runtime response under a tighter inherited limit; no provider was launched locally. ## Target and artifact context No target was loaded. The source scenario concerns a benign local flat EVM hex carrier and an inherited 2147483648-byte address-space soft limit. No chain, RPC, wallet or target execution is involved. ## Interface CLI ## Earliest failure stage Transport or result projection ## Relevant output or evidence Executed source comparison: ```sh git rev-parse HEAD git diff rea-agents-6.7.0 HEAD -- src/evm/EvmoleInterfaceProvider.ts src/evm/EvmWorkerLimits.ts src/evm/EvmoleRelease.ts docs/evm-bytecode.md scripts/verify-evm-interface.mjs ``` Observed HEAD was `3537e58c1ab29309f06eabf50bc52adba9817a0c`; the diff produced no output. Line-numbered source reads established the static path above. The relevant result construction is at provider lines 396–443: the selected configured limit is interpolated, while the later 3 GiB figure is a literal. No captured runtime limitations array is available. ## Typed outcome or recovery expected Retain successful inspection Evidence and its accurate configured-limit entry, with the worker description agreeing with that entry or explicitly identifying a maximum. No new error classification is required by this wording defect. ## Analysis or suspected cause Source-derived: the selected address-space value is available when the limitations array is built, but the later sentence embeds the profile maximum as fixed per-worker prose. Schema validation accepts both strings and Evidence assembly forwards them unchanged. ## Additional context The complete supplied open-and-closed issue snapshot was searched using address-space, configured-limit and EVM inspection terms. No report matching this trigger and expected correction was found. The verification is conclusive static tracing; Linux runtime behavior, frequency and downstream consumption remain unmeasured.

bsakaguchi closed this issue

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

bsakaguchi commented

2026-10-31 00:36:56 +00:00

Author

Owner

@morluto commented on GitHub (Oct 23, 2026):

Resolved on main in 4b2a4e8ea. Successful limitations now explicitly call 3 GiB/30 CPU seconds profile maxima and distinguish configured soft limits retaining tighter inherited values. docs/evm-bytecode.md:112 mirrors the same distinction. This directly satisfies the source-only wording report. No worker/runtime execution claimed; closure is source/docs verification of the requested wording, not effective-limit enforcement qualification.

@morluto commented on GitHub (Oct 23, 2026): Resolved on main in [4b2a4e8ea](https://github.com/morluto/rea/commit/4b2a4e8eaef2d7645db0014b2aee826cd1436997). Successful limitations now explicitly call 3 GiB/30 CPU seconds profile maxima and distinguish configured soft limits retaining tighter inherited values. docs/evm-bytecode.md:112 mirrors the same distinction. This directly satisfies the source-only wording report. No worker/runtime execution claimed; closure is source/docs verification of the requested wording, not effective-limit enforcement qualification.

bsakaguchi referenced this issue

2026-10-31 00:40:20 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425

bsakaguchi referenced this issue

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

[PR #3124] docs(skill): flag hidden-window throttling in passive browser observation #5631

bsakaguchi referenced this issue

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

[GH-ISSUE #3795] [Tracker] Open documentation issues and pull requests (October 2026) #1468