morluto/rea

Fork 0

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

[GH-ISSUE #5708] [Bug] inspect-macho misclassifies a valid dSYM target refusal as a provider execution failure #3457

New issue

Closed

opened 2026-10-31 00:40:41 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

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

inspect-macho on the DWARF member of a locally generated dSYM exits 1 with code and category both execution_failure, no inspection Evidence, and advice to run rea doctor. The captured dyld_info output instead identifies a property of the selected debug companion: section '__TEXT/__text' has offset=0 but is not a zero-fill section type. The same provider successfully inspects the linked executable, its object file, and an executable linked without a UUID.

Reproduction

From a source checkout with locked dependencies installed and the CLI built, run on macOS with Apple command-line tools. Run without shell errexit so expected failures do not stop the controls. The fixtures are inspected without executing them.

work_dir="$(mktemp -d)"
S="$work_dir"
mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp"
printf '#include <stdio.h>\nint g; int main(void){puts("x"); return g;}\n' > "$S/prog.c"
clang -g -O0 -c "$S/prog.c" -o "$S/prog.o"
clang -g -O0 -o "$S/prog" "$S/prog.o"
dsymutil "$S/prog" -o "$S/prog.dSYM"
clang -Wl,-no_uuid -o "$S/no-uuid" "$S/prog.c"
dsym="$S/prog.dSYM/Contents/Resources/DWARF/prog"

file "$dsym"
otool -hv "$dsym"
dyld_info -imports "$dsym"
printf 'dyld_info exit %s\n' "$?"
otool -h -l "$dsym" > "$S/dsym.load.txt"
printf 'otool exit %s\n' "$?"
nm -gjU --no-dyldinfo "$dsym" > "$S/dsym.symbols.txt"
printf 'nm exit %s\n' "$?"
dwarfdump --uuid "$dsym"
printf 'dwarfdump exit %s\n' "$?"

for item in dsym linked object no-uuid; do
  case "$item" in
    dsym) target="$dsym" ;;
    linked) target="$S/prog" ;;
    object) target="$S/prog.o" ;;
    no-uuid) target="$S/no-uuid" ;;
  esac
  env -i PATH="$PATH" HOME=$S/home XDG_CONFIG_HOME=$S/cfg \
    XDG_DATA_HOME=$S/data XDG_CACHE_HOME=$S/cache \
    XDG_STATE_HOME=$S/state TMPDIR=$S/tmp REA_LOG_LEVEL=silent \
    node scripts/rea.mjs inspect-macho "$target" --json \
    > "$S/$item.json" 2> "$S/$item.stderr"
  printf '%s exit %s\n' "$item" "$?"
done
cat "$S/dsym.json"

An independent verifier reproduced the dSYM failure twice at the baseline and ran each REA control once. The submitter freshly built fetched main, generated new fixtures, and ran the script once: the dSYM failed and all three controls succeeded. Direct dyld_info failed with the same section diagnostic; otool, nm, and dwarfdump succeeded.

Expected behavior

Report the target-specific limitation accurately. A typed unsupported-target refusal with the retained diagnostic and target-specific guidance is sufficient if dSYM inspection is unsupported. If readable facets are supported, return those facts with explicit unavailable dyld coverage. Full dSYM analysis support is not required by this report.

Source-derived contract: AnalysisUnsupportedTargetError distinguishes readable unsupported artifacts; ProviderAdapterError is the fallback outside more precise variants. The tool-design contract requires explicit coverage and limitations. This target-layout refusal should not imply broken provider readiness.

Impact and scope

P2, supported: a bounded debug-companion input repeatedly loses its inspection result and receives an incorrect machine-readable category and repair action. Three other native input controls succeed. Full dSYM support, other architectures, real-world frequency, and MCP behavior were not established. No target execution or security-boundary crossing occurred.

An equivalent REA workaround was not verified. Direct native readers expose useful facts, but do not supply REA's normalized Evidence.

REA version

rea-agents 6.7.0; verified baseline 9d8e7803326a382cbbb3ffdb900f5e93e5442d68. Rechecked with npm run build:cached and the public CLI on fetched main ccc7da309d7db385d5c6d73b0a3a8e093be33504 (also 6.7.0): still reproduces. The lockfile was unchanged.

Runtime and platform

Node.js v26.12.0; macOS 27.0.1; arm64; Apple clang 21.0.0 (clang-2100.3.34.2), native dsymutil, dyld_info, otool, nm and dwarfdump. Hopper/Ghidra were not involved.

Target and artifact context

Self-built thin arm64 Mach-O dSYM companion, generated by dsymutil from the inline C fixture. file identifies a Mach-O 64-bit dSYM companion file arm64; otool -hv reports DSYM. Controls use the linked executable, its object file, and a separately linked UUID-less executable from the same source.

Interface

CLI

Earliest failure stage

Native analysis or reconstruction

Relevant output or evidence

Observed on freshly built main:

dyld_info exit 1
otool exit 0
nm exit 0
dwarfdump exit 0
dsym exit 1
linked exit 0
object exit 0
no-uuid exit 0

REA's failing JSON subset, with path-bearing output and byte counts omitted:

{
  "code": "execution_failure",
  "category": "execution_failure",
  "message": "Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.",
  "retryable": false,
  "details": {
    "provider_id": "native-macos",
    "operation": "inspect_macho",
    "diagnostics": {
      "tool": "dyld_info",
      "reason": "nonzero-exit",
      "exit_code": 1,
      "signal": null
    }
  }
}

Captured stdout retains the section diagnostic above; stderr is empty, truncated is false, and there is no signal. Direct nm exposes _main and _g; dwarfdump exposes a UUID. The no-UUID REA control returns null UUID and explicit unavailable import coverage. Evidence provenance: observed.

Typed outcome or recovery expected

Return a target-specific refusal with the retained diagnostic, or supported facts with explicit unavailable dyld coverage. Preserve linked/object success and the no-UUID control's partial coverage. Genuine launcher, signal, capture, and unexpected native-tool failures must remain failures; this is not a request to treat every nonzero native exit as unsupported input or success. These are proposed restoration checks; no fix was implemented or verified.

Analysis or suspected cause

Source-derived reasoning: NativeMachoInspection.ts requires dyld collection and accepts a nonzero dyld exit only through isMissingUuidDyldFailure. This different diagnostic becomes a native command failure, then a generic adapter error in NativeMacOSProvider.ts, and is projected as execution_failure with doctor guidance. The failure is in REA's target-versus-provider classification; no bundled dependency was identified as the cause.

Additional context

Prepared with AI assistance and independently verified against real Apple tools. Distinct from the fixed #5606: the no-UUID control now succeeds, while this different dSYM diagnostic still fails after that fix. No earlier known-good version was established for this dSYM case.

Related but different: #1189 concerns truncated-header admission; #5462 concerns universal ar slices; #5680 concerns legal section/segment names. #1193 and PR #2025 concern loading a matching companion into Ghidra, rather than native inspection error classification.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5708 ### 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 `inspect-macho` on the DWARF member of a locally generated dSYM exits 1 with `code` and `category` both `execution_failure`, no inspection Evidence, and advice to run `rea doctor`. The captured `dyld_info` output instead identifies a property of the selected debug companion: `section '__TEXT/__text' has offset=0 but is not a zero-fill section type`. The same provider successfully inspects the linked executable, its object file, and an executable linked without a UUID. ### Reproduction From a source checkout with locked dependencies installed and the CLI built, run on macOS with Apple command-line tools. Run without shell `errexit` so expected failures do not stop the controls. The fixtures are inspected without executing them. ```sh work_dir="$(mktemp -d)" S="$work_dir" mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp" printf '#include <stdio.h>\nint g; int main(void){puts("x"); return g;}\n' > "$S/prog.c" clang -g -O0 -c "$S/prog.c" -o "$S/prog.o" clang -g -O0 -o "$S/prog" "$S/prog.o" dsymutil "$S/prog" -o "$S/prog.dSYM" clang -Wl,-no_uuid -o "$S/no-uuid" "$S/prog.c" dsym="$S/prog.dSYM/Contents/Resources/DWARF/prog" file "$dsym" otool -hv "$dsym" dyld_info -imports "$dsym" printf 'dyld_info exit %s\n' "$?" otool -h -l "$dsym" > "$S/dsym.load.txt" printf 'otool exit %s\n' "$?" nm -gjU --no-dyldinfo "$dsym" > "$S/dsym.symbols.txt" printf 'nm exit %s\n' "$?" dwarfdump --uuid "$dsym" printf 'dwarfdump exit %s\n' "$?" for item in dsym linked object no-uuid; do case "$item" in dsym) target="$dsym" ;; linked) target="$S/prog" ;; object) target="$S/prog.o" ;; no-uuid) target="$S/no-uuid" ;; esac env -i PATH="$PATH" HOME=$S/home XDG_CONFIG_HOME=$S/cfg \ XDG_DATA_HOME=$S/data XDG_CACHE_HOME=$S/cache \ XDG_STATE_HOME=$S/state TMPDIR=$S/tmp REA_LOG_LEVEL=silent \ node scripts/rea.mjs inspect-macho "$target" --json \ > "$S/$item.json" 2> "$S/$item.stderr" printf '%s exit %s\n' "$item" "$?" done cat "$S/dsym.json" ``` An independent verifier reproduced the dSYM failure twice at the baseline and ran each REA control once. The submitter freshly built fetched main, generated new fixtures, and ran the script once: the dSYM failed and all three controls succeeded. Direct `dyld_info` failed with the same section diagnostic; `otool`, `nm`, and `dwarfdump` succeeded. ### Expected behavior Report the target-specific limitation accurately. A typed unsupported-target refusal with the retained diagnostic and target-specific guidance is sufficient if dSYM inspection is unsupported. If readable facets are supported, return those facts with explicit unavailable dyld coverage. Full dSYM analysis support is not required by this report. Source-derived contract: [`AnalysisUnsupportedTargetError`](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/domain/analysisErrorCore.ts#L7-L22) distinguishes readable unsupported artifacts; [`ProviderAdapterError`](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/domain/providerAdapterError.ts#L6-L14) is the fallback outside more precise variants. The [tool-design contract](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/docs/tool-design.md) requires explicit coverage and limitations. This target-layout refusal should not imply broken provider readiness. ### Impact and scope P2, supported: a bounded debug-companion input repeatedly loses its inspection result and receives an incorrect machine-readable category and repair action. Three other native input controls succeed. Full dSYM support, other architectures, real-world frequency, and MCP behavior were not established. No target execution or security-boundary crossing occurred. An equivalent REA workaround was not verified. Direct native readers expose useful facts, but do not supply REA's normalized Evidence. ### REA version `rea-agents` 6.7.0; verified baseline `9d8e7803326a382cbbb3ffdb900f5e93e5442d68`. Rechecked with `npm run build:cached` and the public CLI on fetched main `ccc7da309d7db385d5c6d73b0a3a8e093be33504` (also 6.7.0): still reproduces. The lockfile was unchanged. ### Runtime and platform Node.js v26.12.0; macOS 27.0.1; arm64; Apple clang 21.0.0 (clang-2100.3.34.2), native dsymutil, dyld_info, otool, nm and dwarfdump. Hopper/Ghidra were not involved. ### Target and artifact context Self-built thin arm64 Mach-O dSYM companion, generated by `dsymutil` from the inline C fixture. `file` identifies a `Mach-O 64-bit dSYM companion file arm64`; `otool -hv` reports `DSYM`. Controls use the linked executable, its object file, and a separately linked UUID-less executable from the same source. ### Interface CLI ### Earliest failure stage Native analysis or reconstruction ### Relevant output or evidence Observed on freshly built main: ```text dyld_info exit 1 otool exit 0 nm exit 0 dwarfdump exit 0 dsym exit 1 linked exit 0 object exit 0 no-uuid exit 0 ``` REA's failing JSON subset, with path-bearing output and byte counts omitted: ```json { "code": "execution_failure", "category": "execution_failure", "message": "Analysis could not complete. Run `rea doctor` and review the reported details; repeating the unchanged request is not expected to succeed.", "retryable": false, "details": { "provider_id": "native-macos", "operation": "inspect_macho", "diagnostics": { "tool": "dyld_info", "reason": "nonzero-exit", "exit_code": 1, "signal": null } } } ``` Captured stdout retains the section diagnostic above; stderr is empty, `truncated` is false, and there is no signal. Direct `nm` exposes `_main` and `_g`; `dwarfdump` exposes a UUID. The no-UUID REA control returns null UUID and explicit unavailable import coverage. Evidence provenance: observed. ### Typed outcome or recovery expected Return a target-specific refusal with the retained diagnostic, or supported facts with explicit unavailable dyld coverage. Preserve linked/object success and the no-UUID control's partial coverage. Genuine launcher, signal, capture, and unexpected native-tool failures must remain failures; this is not a request to treat every nonzero native exit as unsupported input or success. These are proposed restoration checks; no fix was implemented or verified. ### Analysis or suspected cause Source-derived reasoning: [`NativeMachoInspection.ts`](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/native/NativeMachoInspection.ts#L57-L126) requires dyld collection and accepts a nonzero dyld exit only through [`isMissingUuidDyldFailure`](https://github.com/morluto/rea/blob/9d8e7803326a382cbbb3ffdb900f5e93e5442d68/src/native/NativeMachoCommandDiagnostics.ts#L5-L21). This different diagnostic becomes a native command failure, then a generic adapter error in `NativeMacOSProvider.ts`, and is projected as `execution_failure` with doctor guidance. The failure is in REA's target-versus-provider classification; no bundled dependency was identified as the cause. ### Additional context Prepared with AI assistance and independently verified against real Apple tools. Distinct from the fixed [#5606](https://github.com/morluto/rea/issues/5606): the no-UUID control now succeeds, while this different dSYM diagnostic still fails after that fix. No earlier known-good version was established for this dSYM case. Related but different: [#1189](https://github.com/morluto/rea/issues/1189) concerns truncated-header admission; [#5462](https://github.com/morluto/rea/issues/5462) concerns universal ar slices; [#5680](https://github.com/morluto/rea/issues/5680) concerns legal section/segment names. [#1193](https://github.com/morluto/rea/issues/1193) and [PR #2025](https://github.com/morluto/rea/pull/2025) concern loading a matching companion into Ghidra, rather than native inspection error classification.

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

Additional trigger for this same target-versus-provider classification failure: a synthetic readable thin arm64 MH_CORE header with LC_SEGMENT_64 and LC_UUID. file identifies a Mach-O core; otool -hv -l exits 0 and reads both commands. Both dyld_info modes exit 1 with unknown mh.filetype 4. REA exits 1 with code and category both execution_failure, no inspection Evidence, and advice to run rea doctor. Captured stdout retains the filetype diagnostic; stderr is empty, capture is not truncated, and there is no signal.

The same script also demonstrates a supplemental MH_FVMLIB readable-header trigger with unknown mh.filetype 3 and the same REA outcome. That fixture omits the obsolete format's LC_IDFVMLIB, so it does not establish behavior for a complete conforming historical FVMLIB. The CORE fixture is synthetic, not an operating-system-generated dump. Neither target is executed.

Reproduced twice per filetype by an independent verifier at baseline 9d8e7803326a382cbbb3ffdb900f5e93e5442d68. I freshly built fetched main 9258df02cc414112d4fa91a425f0d599f43e2357 with npm run build:cached and ran the following script once: both failures persist and the linked arm64 executable control returns inspection Evidence with exit 0. Main is rea-agents 6.7.0, tested with pinned Node.js v24.18.0 on macOS 27.0.1 arm64 and Apple command-line tools. The lockfile was unchanged.

From the built source checkout on macOS, run without shell errexit:

work_dir="$(mktemp -d)"
S="$work_dir"
mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp"
python3 -I - "$S" <<'PYFIXTURE'
import struct
import sys
from pathlib import Path

out = Path(sys.argv[1])
segment = struct.pack('<II16sQQQQiiII', 0x19, 72, b'__TEXT',
                      0x100000000, 0x4000, 0, 4096, 7, 5, 0, 0)
uuid = struct.pack('<II16s', 0x1b, 24, bytes(range(16)))
commands = segment + uuid
for name, filetype in [('core', 4), ('fvmlib', 3)]:
    header = struct.pack('<IiiIIIII', 0xfeedfacf, 0x0100000c, 0,
                         filetype, 2, len(commands), 0, 0)
    (out / name).write_bytes((header + commands).ljust(4096, b'\0'))
PYFIXTURE
for kind in core fvmlib; do
  file "$S/$kind"
  otool -hv -l "$S/$kind" > "$S/$kind.otool.txt" 2>&1
  printf '%s otool exit=%s\n' "$kind" "$?"
  for mode in imports exports; do
    dyld_info -"$mode" "$S/$kind" > "$S/$kind.dyld-$mode.txt" 2>&1
    printf '%s dyld-%s exit=%s\n' "$kind" "$mode" "$?"
    head -3 "$S/$kind.dyld-$mode.txt"
  done
  env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \
    XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \
    XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \
    node scripts/rea.mjs inspect-macho "$S/$kind" --json \
    > "$S/$kind.json" 2> "$S/$kind.stderr"
  printf '%s rea exit=%s\n' "$kind" "$?"
done
printf 'int main(void) { return 0; }\n' > "$S/control.c"
clang -arch arm64 -o "$S/control" "$S/control.c"
env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \
  XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \
  XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \
  node scripts/rea.mjs inspect-macho "$S/control" --json \
  > "$S/control.json" 2> "$S/control.stderr"
printf 'control rea exit=%s\n' "$?"
cat "$S/core.json"
cat "$S/fvmlib.json"

Observed exit summary on main:

core:   otool=0, dyld-imports=1, dyld-exports=1, rea=1
fvmlib: otool=0, dyld-imports=1, dyld-exports=1, rea=1
control: rea=0

A target-specific unsupported refusal retaining the filetype reason and giving target-selection guidance is sufficient for CORE. Supported facts with explicit unavailable dyld coverage would also satisfy the contract. The supplemental FVMLIB case needs an accurate target-related refusal or limitation without implying that provider repair will make the incomplete historical fixture supported.

Source-derived reasoning: the required dyld collection in NativeMachoInspection.ts accepts a nonzero exit only through isMissingUuidDyldFailure; this different diagnostic reaches the generic adapter-error translation in NativeMacOSProvider.ts. Both fixtures include LC_UUID, so this is distinct from fixed #5606 and shares this issue's classification path. Genuine launcher, capture, signal, and unexpected native-tool failures must remain failures.

@coygeek commented on GitHub (Oct 20, 2026): Additional trigger for this same target-versus-provider classification failure: a synthetic readable thin arm64 `MH_CORE` header with `LC_SEGMENT_64` and `LC_UUID`. `file` identifies a Mach-O core; `otool -hv -l` exits 0 and reads both commands. Both `dyld_info` modes exit 1 with `unknown mh.filetype 4`. REA exits 1 with `code` and `category` both `execution_failure`, no inspection Evidence, and advice to run `rea doctor`. Captured stdout retains the filetype diagnostic; stderr is empty, capture is not truncated, and there is no signal. The same script also demonstrates a supplemental `MH_FVMLIB` readable-header trigger with `unknown mh.filetype 3` and the same REA outcome. That fixture omits the obsolete format's `LC_IDFVMLIB`, so it does not establish behavior for a complete conforming historical FVMLIB. The CORE fixture is synthetic, not an operating-system-generated dump. Neither target is executed. Reproduced twice per filetype by an independent verifier at baseline `9d8e7803326a382cbbb3ffdb900f5e93e5442d68`. I freshly built fetched main `9258df02cc414112d4fa91a425f0d599f43e2357` with `npm run build:cached` and ran the following script once: both failures persist and the linked arm64 executable control returns inspection Evidence with exit 0. Main is `rea-agents` 6.7.0, tested with pinned Node.js v24.18.0 on macOS 27.0.1 arm64 and Apple command-line tools. The lockfile was unchanged. From the built source checkout on macOS, run without shell `errexit`: ```sh work_dir="$(mktemp -d)" S="$work_dir" mkdir -p "$S/home" "$S/cfg" "$S/data" "$S/cache" "$S/state" "$S/tmp" python3 -I - "$S" <<'PYFIXTURE' import struct import sys from pathlib import Path out = Path(sys.argv[1]) segment = struct.pack('<II16sQQQQiiII', 0x19, 72, b'__TEXT', 0x100000000, 0x4000, 0, 4096, 7, 5, 0, 0) uuid = struct.pack('<II16s', 0x1b, 24, bytes(range(16))) commands = segment + uuid for name, filetype in [('core', 4), ('fvmlib', 3)]: header = struct.pack('<IiiIIIII', 0xfeedfacf, 0x0100000c, 0, filetype, 2, len(commands), 0, 0) (out / name).write_bytes((header + commands).ljust(4096, b'\0')) PYFIXTURE for kind in core fvmlib; do file "$S/$kind" otool -hv -l "$S/$kind" > "$S/$kind.otool.txt" 2>&1 printf '%s otool exit=%s\n' "$kind" "$?" for mode in imports exports; do dyld_info -"$mode" "$S/$kind" > "$S/$kind.dyld-$mode.txt" 2>&1 printf '%s dyld-%s exit=%s\n' "$kind" "$mode" "$?" head -3 "$S/$kind.dyld-$mode.txt" done env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \ XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \ XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \ node scripts/rea.mjs inspect-macho "$S/$kind" --json \ > "$S/$kind.json" 2> "$S/$kind.stderr" printf '%s rea exit=%s\n' "$kind" "$?" done printf 'int main(void) { return 0; }\n' > "$S/control.c" clang -arch arm64 -o "$S/control" "$S/control.c" env -i PATH="$PATH" HOME="$S/home" XDG_CONFIG_HOME="$S/cfg" \ XDG_DATA_HOME="$S/data" XDG_CACHE_HOME="$S/cache" \ XDG_STATE_HOME="$S/state" TMPDIR="$S/tmp" REA_LOG_LEVEL=silent \ node scripts/rea.mjs inspect-macho "$S/control" --json \ > "$S/control.json" 2> "$S/control.stderr" printf 'control rea exit=%s\n' "$?" cat "$S/core.json" cat "$S/fvmlib.json" ``` Observed exit summary on main: ```text core: otool=0, dyld-imports=1, dyld-exports=1, rea=1 fvmlib: otool=0, dyld-imports=1, dyld-exports=1, rea=1 control: rea=0 ``` A target-specific unsupported refusal retaining the filetype reason and giving target-selection guidance is sufficient for CORE. Supported facts with explicit unavailable dyld coverage would also satisfy the contract. The supplemental FVMLIB case needs an accurate target-related refusal or limitation without implying that provider repair will make the incomplete historical fixture supported. Source-derived reasoning: the required dyld collection in [`NativeMachoInspection.ts`](https://github.com/morluto/rea/blob/9258df02cc414112d4fa91a425f0d599f43e2357/src/native/NativeMachoInspection.ts) accepts a nonzero exit only through `isMissingUuidDyldFailure`; this different diagnostic reaches the generic adapter-error translation in `NativeMacOSProvider.ts`. Both fixtures include `LC_UUID`, so this is distinct from fixed #5606 and shares this issue's classification path. Genuine launcher, capture, signal, and unexpected native-tool failures must remain failures.

bsakaguchi commented

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

Author

Owner

@coygeek commented on GitHub (Oct 24, 2026):

The original dSYM case has made concrete progress at d87e73f: inspection now returns a target-specific unsupported error for the unbacked-text diagnostic when the parsed filetype identifies a dSYM, retaining the diagnostic and recommending the matching linked executable. The regression assertions cover numeric 10/DSYM and keep the same diagnostic on executable type 2 as a failure. These assertions use mocked captures; I did not run them or Apple tools.

The later MH_CORE extension is still a separate closure gap. The accepted nonzero dyld diagnostics recognize missing UUID and the exact unbacked-text message, not the reported unknown mh.filetype 4. An unaccepted nonzero result still reaches the generic provider-error fallback. This is current source-derived reasoning; the CORE runtime observations remain those reported in the comment.

Keeping this open should focus on that classification gap, without requiring full core-dump analysis. Closure needs the posted synthetic CORE fixture checked on current main and returned as a target-specific refusal retaining the filetype reason and useful target-selection guidance, or partial inspection with explicit unavailable dyld coverage. Preserve successful linked/object/no-UUID controls and genuine launcher, capture, signal and unexpected-command failures.

The supplemental MH_FVMLIB fixture omits LC_IDFVMLIB; it does not establish support requirements for a complete historical FVMLIB. Its limitation must not be described as evidence that provider repair would make that incomplete fixture supported.

@coygeek commented on GitHub (Oct 24, 2026): The original dSYM case has made concrete progress at `d87e73f`: [inspection now returns a target-specific unsupported error](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/native/NativeMachoInspection.ts#L188-L203) for the unbacked-text diagnostic when the parsed filetype identifies a dSYM, retaining the diagnostic and recommending the matching linked executable. The [regression assertions](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/native/NativeMachoInspection.test.ts#L407-L452) cover numeric `10`/`DSYM` and keep the same diagnostic on executable type `2` as a failure. These assertions use mocked captures; I did not run them or Apple tools. The later `MH_CORE` extension is still a separate closure gap. The [accepted nonzero dyld diagnostics](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/native/NativeMachoCommandDiagnostics.ts#L8-L40) recognize missing UUID and the exact unbacked-text message, not the reported `unknown mh.filetype 4`. An unaccepted nonzero result still reaches the [generic provider-error fallback](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/native/NativeCommandAnalysisError.ts#L197-L210). This is current source-derived reasoning; the CORE runtime observations remain those reported in the comment. Keeping this open should focus on that classification gap, without requiring full core-dump analysis. Closure needs the posted synthetic CORE fixture checked on current main and returned as a target-specific refusal retaining the filetype reason and useful target-selection guidance, or partial inspection with explicit unavailable dyld coverage. Preserve successful linked/object/no-UUID controls and genuine launcher, capture, signal and unexpected-command failures. The supplemental `MH_FVMLIB` fixture omits `LC_IDFVMLIB`; it does not establish support requirements for a complete historical FVMLIB. Its limitation must not be described as evidence that provider repair would make that incomplete fixture supported.

bsakaguchi referenced this issue

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

[PR #3457] [MERGED] fix(native): keep export names ending in a carriage return #5748

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

No description provided.

Rows
Columns