[GH-ISSUE #1956] [Bug] Valid WASM DataCount sections are rejected by WABT output parsing #650

Closed
opened 2026-10-15 18:26:57 +00:00 by bsakaguchi · 2 comments
Owner

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

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

inspect_wasm_artifact and rea inspect-wasm-artifact return unreadable_output with reason Unrecognized WABT section row. for valid WebAssembly v1 modules containing a DataCount section. The configured WABT 1.0.42 validator succeeds; REA rejects the subsequent section table.

The failure reproduces through the source-built CLI and a fresh stdio MCP client on two unchanged released modules (94,519 and 879,148 bytes). Both preserve captured producer output, source bytes and following MCP-call usability. An empty module succeeds with matching CLI/MCP Evidence, so this is not missing-tool configuration or native admission.

Reproduction

With caller-supplied WABT 1.0.42, compile this local source with wat2wasm module.wat -o module.wasm:

(module
  (memory 1)
  (data "x")
  (func (export "init")
    i32.const 0
    i32.const 0
    i32.const 1
    memory.init 0
    data.drop 0))
  1. wasm-validate --enable-all module.wasm succeeds.
  2. wasm-objdump -h module.wasm prints a DataCount row with no leading padding.
  3. Set absolute REA_WABT_BIN_DIRECTORY to the selected WABT directory.
  4. rea inspect-wasm-artifact /absolute/path/module.wasm --format json, or call inspect_wasm_artifact with the same absolute path.

Expected behavior

Accept the pinned producer's legal section-table padding and retain complete inline Evidence for valid modules. Preserve exact output, section ranges, custom-name framing, artifact identity, invalid-input failures and resource limits.

Impact and scope

Bulk-memory modules emitted with a DataCount section cannot be inspected through the advertised WABT lane. An unrelated native provider change or repeated setup cannot repair this representation mismatch. No target execution or byte mutation is required.

REA version

6.4.0; source main 1449e8e05138bf0c86d5fe6f4c93122b4b93b2b1, with the WASM native-route diagnostic from #1872. The failing WABT parser is unchanged from main.

Runtime and platform

Node.js 24.18.0; npm 11.16.0; Linux x86_64; caller-supplied WABT 1.0.42.

Target and artifact context

Valid WebAssembly v1 modules containing a DataCount section.

Interface

CLI and MCP.

Earliest failure stage

Native analysis or reconstruction: parsing the artifact adapter's producer output, after successful validation.

Relevant output or evidence

DataCount start=0x00000023 end=0x00000024 (size=0x00000001) count: 1
code: unreadable_output
category: execution_failure
operation: inspect_wasm_artifact
reason: Unrecognized WABT section row.

Typed outcome or recovery expected

Successful inspect_wasm_artifact Evidence, with valid section coverage and retained decoded WAT. Unsupported producer output must continue to fail truthfully.

Analysis or suspected cause

Source-derived: src/wasm/WabtOutput.ts requires one or more spaces/tabs before every section kind. The pinned producer right-aligns names in a fixed-width column; DataCount fills that column and consequently has zero leading padding. The adapter rejects this legal row before constructing Evidence.

Additional context

The existing real-WABT verification workflow passes its 24 cases, which do not include a bulk-memory DataCount module. Add the reduced source to the real public CLI/MCP workflow and retain malformed-output and section-range coverage.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1956 ### 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 `inspect_wasm_artifact` and `rea inspect-wasm-artifact` return `unreadable_output` with reason `Unrecognized WABT section row.` for valid WebAssembly v1 modules containing a DataCount section. The configured WABT 1.0.42 validator succeeds; REA rejects the subsequent section table. The failure reproduces through the source-built CLI and a fresh stdio MCP client on two unchanged released modules (94,519 and 879,148 bytes). Both preserve captured producer output, source bytes and following MCP-call usability. An empty module succeeds with matching CLI/MCP Evidence, so this is not missing-tool configuration or native admission. ### Reproduction With caller-supplied WABT 1.0.42, compile this local source with `wat2wasm module.wat -o module.wasm`: ```wat (module (memory 1) (data "x") (func (export "init") i32.const 0 i32.const 0 i32.const 1 memory.init 0 data.drop 0)) ``` 1. `wasm-validate --enable-all module.wasm` succeeds. 2. `wasm-objdump -h module.wasm` prints a DataCount row with no leading padding. 3. Set absolute `REA_WABT_BIN_DIRECTORY` to the selected WABT directory. 4. `rea inspect-wasm-artifact /absolute/path/module.wasm --format json`, or call `inspect_wasm_artifact` with the same absolute path. ### Expected behavior Accept the pinned producer's legal section-table padding and retain complete inline Evidence for valid modules. Preserve exact output, section ranges, custom-name framing, artifact identity, invalid-input failures and resource limits. ### Impact and scope Bulk-memory modules emitted with a DataCount section cannot be inspected through the advertised WABT lane. An unrelated native provider change or repeated setup cannot repair this representation mismatch. No target execution or byte mutation is required. ### REA version 6.4.0; source main `1449e8e05138bf0c86d5fe6f4c93122b4b93b2b1`, with the WASM native-route diagnostic from #1872. The failing WABT parser is unchanged from main. ### Runtime and platform Node.js 24.18.0; npm 11.16.0; Linux x86_64; caller-supplied WABT 1.0.42. ### Target and artifact context Valid WebAssembly v1 modules containing a DataCount section. ### Interface CLI and MCP. ### Earliest failure stage Native analysis or reconstruction: parsing the artifact adapter's producer output, after successful validation. ### Relevant output or evidence ```text DataCount start=0x00000023 end=0x00000024 (size=0x00000001) count: 1 code: unreadable_output category: execution_failure operation: inspect_wasm_artifact reason: Unrecognized WABT section row. ``` ### Typed outcome or recovery expected Successful `inspect_wasm_artifact` Evidence, with valid section coverage and retained decoded WAT. Unsupported producer output must continue to fail truthfully. ### Analysis or suspected cause Source-derived: `src/wasm/WabtOutput.ts` requires one or more spaces/tabs before every section kind. The pinned producer right-aligns names in a fixed-width column; `DataCount` fills that column and consequently has zero leading padding. The adapter rejects this legal row before constructing Evidence. ### Additional context The existing real-WABT verification workflow passes its 24 cases, which do not include a bulk-memory DataCount module. Add the reduced source to the real public CLI/MCP workflow and retain malformed-output and section-range coverage.
Author
Owner

@sathariels commented on GitHub (Oct 11, 2026):

I'd like to take this one. The fix looks like allowing zero leading spaces in the section-row pattern in src/wasm/WabtOutput.ts ([ \t]+ -> [ \t]*), since WABT right-aligns DataCount with no padding. I'll add the unpadded row to the parser tests, keep the malformed-output and bad-range rejections, and add your .wat module to the real-WABT check in scripts/verify-wasm-artifact.mjs.

<!-- gh-comment-id:6113755541 --> @sathariels commented on GitHub (Oct 11, 2026): I'd like to take this one. The fix looks like allowing zero leading spaces in the section-row pattern in `src/wasm/WabtOutput.ts` (`[ \t]+` -> `[ \t]*`), since WABT right-aligns `DataCount` with no padding. I'll add the unpadded row to the parser tests, keep the malformed-output and bad-range rejections, and add your `.wat` module to the real-WABT check in `scripts/verify-wasm-artifact.mjs`.
Author
Owner

@N0zoM1z0 commented on GitHub (Oct 11, 2026):

Verified the integrated fixes from #1963 and #1967 through the source-built CLI and a fresh stdio MCP client using caller-supplied WABT 1.0.42.

  • Both unchanged released modules (94,519 and 879,148 bytes) now validate and return complete inspection Evidence, including DataCount sections.
  • The smaller module returns inline Evidence with 1,441,153 bytes of decoded WAT.
  • The larger module has 15,350,577 bytes of decoded WAT. The default MCP receive budget produces an explicit transport constraint; exporting retained Evidence yields the complete result, exactly matching CLI JSON. No response budget was increased.
  • Artifact digests remain unchanged, Evidence digests agree, and subsequent MCP pings succeed.
  • Missing WABT remains a distinct capability_unavailable outcome.
  • The current real WABT CLI/MCP verifier passes 42 cases, with verified process lineage and no surviving owned descendants.

The fresh-client recovery run used one CPU and a 3 GiB memory cap, peaked at 1,399,619,584 bytes, and reported zero memory-limit/OOM events. This confirms the original DataCount failure is resolved without truncating the large result.

<!-- gh-comment-id:6114254106 --> @N0zoM1z0 commented on GitHub (Oct 11, 2026): Verified the integrated fixes from #1963 and #1967 through the source-built CLI and a fresh stdio MCP client using caller-supplied WABT 1.0.42. - Both unchanged released modules (94,519 and 879,148 bytes) now validate and return complete inspection Evidence, including DataCount sections. - The smaller module returns inline Evidence with 1,441,153 bytes of decoded WAT. - The larger module has 15,350,577 bytes of decoded WAT. The default MCP receive budget produces an explicit transport constraint; exporting retained Evidence yields the complete result, exactly matching CLI JSON. No response budget was increased. - Artifact digests remain unchanged, Evidence digests agree, and subsequent MCP pings succeed. - Missing WABT remains a distinct `capability_unavailable` outcome. - The current real WABT CLI/MCP verifier passes **42 cases**, with verified process lineage and no surviving owned descendants. The fresh-client recovery run used one CPU and a 3 GiB memory cap, peaked at 1,399,619,584 bytes, and reported zero memory-limit/OOM events. This confirms the original DataCount failure is resolved without truncating the large result.
Sign in to join this conversation.
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#650
No description provided.