[GH-ISSUE #6599] [Bug] GPU exact target filters match unknown targets when given an empty string #3985

Closed
opened 2026-10-31 00:45:48 +00:00 by bsakaguchi · 0 comments
Owner

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

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

A GPU targets page requested with targets: [""] returns an AMDGPU target row whose retained target is null. The empty string and an unknown target are distinct values, so this is a false positive in the documented exact filter. The public CLI and the current source service both returned that row. An objects page through the source service likewise returned the unknown-target object for the empty-string filter.

Reproduction

Use the source checkout and pinned runtime described below, with locked dependencies and its CLI already built. Set REA_CHECKOUT to that checkout and run from a disposable directory. The first command writes the exact 336-byte synthetic fixture used in the observations; it contains an ELF64 AMDGPU header and an AMDGPU MessagePack v3 note with metadata version [1,0], an empty kernel array, and no target string. No GPU tool, driver, target execution, or external provider is needed.

node -e 'require("node:fs").writeFileSync("no-target-v3.o", Buffer.from("7f454c460201014000000000000000000100e000010000000000000000000000000000000000000090000000000000002c010000400000000000400003000100002e7368737472746162002e6e6f746500000000070000002300000020000000414d44475055000082ae616d646873612e76657273696f6e920100ae616d646873612e6b65726e656c7390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000300000000000000000000000000000000000000400000000000000011000000000000000000000000000000010000000000000000000000000000000b000000070000000000000000000000000000000000000054000000000000003800000000000000000000000000000004000000000000000000000000000000", "hex"))'
node "$REA_CHECKOUT/scripts/rea.mjs" inspect-gpu-code-objects no-target-v3.o --detail summary --view '{"collection":"targets","targets":[""]}' --evidence_output filter.evidence.json --json

Use a fresh filter.evidence.json destination. The successful CLI invocation was executed once. Before drafting, a separate source-service probe also exercised an unfiltered targets page, [""], ["sm_80"], [], and an objects page with [""]; the result matrix is below. The fixture is synthetic rather than compiler-produced. LLVM llvm-readobj --file-headers --notes 23.1.3 independently recognized its ELF and AMDGPU metadata. Its SHA-256 is b959555076a13518555c7715d1027e6c39d257420036832537f97d0f8e2b84a2.

Expected behavior

The empty-string exact filter should return no row for a retained target: null; alternatively, validation could reject an empty target selector explicitly. REA promises exact filters for GPU pages, while the selection schema currently accepts empty strings. The fixture's absent target is valid for the supported metadata generation: LLVM's published code-object metadata specification identifies amdhsa.target as a code-object-v4 addition to v3 metadata.

Impact and scope

This is a bounded incorrect-selection result for callers using an empty string as a GPU page target filter when retained facts have unknown targets. It can include objects or target groups outside the requested exact value. Original target values remain null in the returned rows, and no target declaration or input file is modified. The targets and objects collections were observed; kernels and additional container variants were not exercised. No GPU execution or general runtime-compatibility claim is involved. Clients can discard rows whose returned target differs from the requested string; applying that comparison to the observed targets page produced zero rows.

REA version

Package version 6.7.0; source main at 0154141304028645d767bad32a1f7568b5d4815b. The CLI used that checkout's built runtime, and the source-service probe independently observed the same failure. The supplied latest published release is rea-agents-6.7.0 at 27dc42d10249f0410904a75c0997842eb03b931c; GPU support is main-only relative to that release, so this report does not claim a published-package failure.

Runtime and platform

Node.js v24.22.1; Linux x86_64, kernel 7.2.8-9-omarchy; Omarchy 4.0.6. Static GPU reader; no Hopper, Ghidra, CUDA runtime, or GPU device was used. LLVM readobj 23.1.3 was used only to inspect the synthetic fixture independently.

Target and artifact context

Synthetic 336-byte ELF64 little-endian AMDGPU relocatable object, OS ABI AMDGPU_HSA, v3 metadata version [1,0], zero kernel declarations, and an absent amdhsa.target. The report correctly retains its target as unknown before applying the page filter.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Selected fields from the successful CLI's summary.normalized_result:

{
  "view": {"collection":"targets","targets":[""]},
  "items": [{"id":"target:null","target":null,"object_count":1}],
  "coverage": {"status":"page","examined":1,"total":1,"exhausted":true}
}

The source-service control matrix returned:

unfiltered targets:          [{"id":"target:null","target":null}]
targets [""]:                [{"id":"target:null","target":null}]
targets ["sm_80"]:           []
targets []:                  []
objects with targets [""]:   [{"id":"file@0","target":null}]
  • Expected source: The linked exact-filter documentation and accepted target-selector schema at the stated source revision.
  • Failure source: The executed public CLI and source-service results above; the GPU projection predicate provides the source-derived explanation.
  • Evidence provenance: observed; the predicate explanation is separately source-derived.
  • Local verification: reproduced.
  • Reproduction completeness: complete.

Typed outcome or recovery expected

Return an empty page for [""] against this unknown-target fixture, or reject that selector with a typed input error before projection. A restoration check should retain the unfiltered null-target row while ensuring an exact string filter cannot select it. Existing nonmatching-string and empty-set controls should remain empty. This check is proposed, not a claim that restoration has been tested.

Analysis or suspected cause

Source-derived: the page predicate converts a null target to "" before set membership. That conversion changes the lookup identity while the projected row continues to expose target: null. The supported CLI passes the requested view to the retained projection after collecting the source Evidence; the source-service probe also exercised the normal Evidence validation and projection boundary.

Additional context

The first two CLI attempts stopped at input admission because summary detail and then the required evidence output were omitted; the reproduction above includes both and reached the observed false-positive page. No source fix, release comparison, or GPU execution was performed.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: The supported exact-filter request returns an unknown-target group and object outside the requested string value; both results were directly observed and the scope is bounded to this selector/value combination.
  • Workaround status: available
  • Workaround basis: The returned target remains explicitly null, and applying the requested exact comparison to the observed targets page removed the false-positive row without changing source bytes or losing any matching row.
Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6599 ## 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 A GPU targets page requested with `targets: [""]` returns an AMDGPU target row whose retained `target` is `null`. The empty string and an unknown target are distinct values, so this is a false positive in the documented exact filter. The public CLI and the current source service both returned that row. An objects page through the source service likewise returned the unknown-target object for the empty-string filter. ## Reproduction Use the source checkout and pinned runtime described below, with locked dependencies and its CLI already built. Set `REA_CHECKOUT` to that checkout and run from a disposable directory. The first command writes the exact 336-byte synthetic fixture used in the observations; it contains an ELF64 AMDGPU header and an AMDGPU MessagePack v3 note with metadata version `[1,0]`, an empty kernel array, and no target string. No GPU tool, driver, target execution, or external provider is needed. ```sh node -e 'require("node:fs").writeFileSync("no-target-v3.o", Buffer.from("7f454c460201014000000000000000000100e000010000000000000000000000000000000000000090000000000000002c010000400000000000400003000100002e7368737472746162002e6e6f746500000000070000002300000020000000414d44475055000082ae616d646873612e76657273696f6e920100ae616d646873612e6b65726e656c7390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000300000000000000000000000000000000000000400000000000000011000000000000000000000000000000010000000000000000000000000000000b000000070000000000000000000000000000000000000054000000000000003800000000000000000000000000000004000000000000000000000000000000", "hex"))' node "$REA_CHECKOUT/scripts/rea.mjs" inspect-gpu-code-objects no-target-v3.o --detail summary --view '{"collection":"targets","targets":[""]}' --evidence_output filter.evidence.json --json ``` Use a fresh `filter.evidence.json` destination. The successful CLI invocation was executed once. Before drafting, a separate source-service probe also exercised an unfiltered targets page, `[""]`, `["sm_80"]`, `[]`, and an objects page with `[""]`; the result matrix is below. The fixture is synthetic rather than compiler-produced. LLVM `llvm-readobj --file-headers --notes` 23.1.3 independently recognized its ELF and AMDGPU metadata. Its SHA-256 is `b959555076a13518555c7715d1027e6c39d257420036832537f97d0f8e2b84a2`. ## Expected behavior The empty-string exact filter should return no row for a retained `target: null`; alternatively, validation could reject an empty target selector explicitly. REA promises [exact filters for GPU pages](https://github.com/morluto/rea/blob/0154141304028645d767bad32a1f7568b5d4815b/docs/gpu-code-objects.md#L15-L19), while the [selection schema](https://github.com/morluto/rea/blob/0154141304028645d767bad32a1f7568b5d4815b/src/domain/gpu/gpuCodeObjects.ts#L312-L317) currently accepts empty strings. The fixture's absent target is valid for the supported metadata generation: LLVM's [published code-object metadata specification](https://releases.llvm.org/12.0.0/docs/AMDGPUUsage.html#code-object-v4-metadata) identifies `amdhsa.target` as a code-object-v4 addition to v3 metadata. ## Impact and scope This is a bounded incorrect-selection result for callers using an empty string as a GPU page target filter when retained facts have unknown targets. It can include objects or target groups outside the requested exact value. Original target values remain null in the returned rows, and no target declaration or input file is modified. The targets and objects collections were observed; kernels and additional container variants were not exercised. No GPU execution or general runtime-compatibility claim is involved. Clients can discard rows whose returned `target` differs from the requested string; applying that comparison to the observed targets page produced zero rows. ## REA version Package version 6.7.0; source main at `0154141304028645d767bad32a1f7568b5d4815b`. The CLI used that checkout's built runtime, and the source-service probe independently observed the same failure. The supplied latest published release is `rea-agents-6.7.0` at `27dc42d10249f0410904a75c0997842eb03b931c`; GPU support is main-only relative to that release, so this report does not claim a published-package failure. ## Runtime and platform Node.js v24.22.1; Linux x86_64, kernel 7.2.8-9-omarchy; Omarchy 4.0.6. Static GPU reader; no Hopper, Ghidra, CUDA runtime, or GPU device was used. LLVM readobj 23.1.3 was used only to inspect the synthetic fixture independently. ## Target and artifact context Synthetic 336-byte ELF64 little-endian AMDGPU relocatable object, OS ABI AMDGPU_HSA, v3 metadata version `[1,0]`, zero kernel declarations, and an absent `amdhsa.target`. The report correctly retains its target as unknown before applying the page filter. ## Interface CLI ## Earliest failure stage Transport or result projection ## Relevant output or evidence Selected fields from the successful CLI's `summary.normalized_result`: ```json { "view": {"collection":"targets","targets":[""]}, "items": [{"id":"target:null","target":null,"object_count":1}], "coverage": {"status":"page","examined":1,"total":1,"exhausted":true} } ``` The source-service control matrix returned: ```text unfiltered targets: [{"id":"target:null","target":null}] targets [""]: [{"id":"target:null","target":null}] targets ["sm_80"]: [] targets []: [] objects with targets [""]: [{"id":"file@0","target":null}] ``` - Expected source: The linked exact-filter documentation and accepted target-selector schema at the stated source revision. - Failure source: The executed public CLI and source-service results above; the [GPU projection predicate](https://github.com/morluto/rea/blob/0154141304028645d767bad32a1f7568b5d4815b/src/domain/analysisView/gpuCodeObjectsView.ts#L347-L357) provides the source-derived explanation. - Evidence provenance: observed; the predicate explanation is separately source-derived. - Local verification: reproduced. - Reproduction completeness: complete. ## Typed outcome or recovery expected Return an empty page for `[""]` against this unknown-target fixture, or reject that selector with a typed input error before projection. A restoration check should retain the unfiltered null-target row while ensuring an exact string filter cannot select it. Existing nonmatching-string and empty-set controls should remain empty. This check is proposed, not a claim that restoration has been tested. ## Analysis or suspected cause Source-derived: the page predicate converts a null target to `""` before set membership. That conversion changes the lookup identity while the projected row continues to expose `target: null`. The supported CLI passes the requested view to the retained projection after collecting the source Evidence; the source-service probe also exercised the normal Evidence validation and projection boundary. ## Additional context The first two CLI attempts stopped at input admission because summary detail and then the required evidence output were omitted; the reproduction above includes both and reached the observed false-positive page. No source fix, release comparison, or GPU execution was performed. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: The supported exact-filter request returns an unknown-target group and object outside the requested string value; both results were directly observed and the scope is bounded to this selector/value combination. - Workaround status: available - Workaround basis: The returned target remains explicitly null, and applying the requested exact comparison to the observed targets page removed the false-positive row without changing source bytes or losing any matching row.
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#3985
No description provided.