morluto/rea

Fork 0

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

[GH-ISSUE #4322] [Bug] Linux exit race reports an exited owned process as a token mismatch #1717

New issue

Open

opened 2026-10-16 21:09:24 +00:00 by bsakaguchi · 7 comments

bsakaguchi commented

2026-10-16 21:09:24 +00:00

Owner

Originally created by @SII-YDD on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4322

Before submitting

Searched open/closed issues and PRs for environ cleanup, token mismatch, and empty environment.
No credentials, complete environment contents, or private targets are included.

Area

Process capture or runtime observation

Observed behavior

An owned Node child that acknowledges shutdown and then exits naturally can make cleanupOwnedProcessGroup return cleaned:false with process ownership token mismatch. A fresh observation at the missing-token read finds that PID already zombie or absent. After the actual child exit event, a cleanup retry succeeds without signaling anything.

Observed in an isolated Linux arm64 container using actual Node processes, independent of Hopper/Jadx. One bounded100-case diagnostic run produced6 initial failures; every one of the100 post-exit retries reported cleaned. These counts describe this run, not an estimated failure probability.

Reproduction

Build the source (npm ci, npm run build:cached). The attached reduced reproducer uses the compiled production modules and starts100 source-owned Node children, each with an exact run token via spawnOwnedProviderProcess. Each child writes ready, acknowledges a stdin shutdown request, then exits after1..5ms. Immediately after the acknowledgement, call cleanupOwnedProcessGroup; record a fresh /proc/PID/stat state only when the production environment reader returns no run token. Join the exit event and call cleanup again. All children are joined and all groups are verified cleaned.

A100-case immediate-cleanup control without acknowledgement/delayed exit had0 failures. The acknowledgement/exit interleaving exposes the issue; no test retries, skip, assertion, timeout or ownership policy was changed. Full executable script follows.

import { readFile } from 'node:fs/promises';
import { once } from 'node:events';
import { spawnOwnedProviderProcess } from './dist/process/ProviderProcess.js';
import { cleanupOwnedProcessGroup } from './dist/process/ProcessOwnership.js';
import { systemProcessOwnershipHost } from './dist/process/ProcessOwnershipObservation.js';
const results=[];
for(let i=0;i<100;i++) {
  const observations=[];
  const spawned=await spawnOwnedProviderProcess({command:process.execPath,arguments:['-e','process.stdin.once("data",()=>{process.stdout.write("ack"); setTimeout(()=>process.exit(0),Number(process.argv[1]));}); process.stdout.write("ready");',String(1+i%5)],runId:`rea-ci-20261016-${i}`,expectedCommand:null,stdin:'pipe'});
  const child=spawned.process;
  const exit=once(child,'exit');
  const ready=once(child.stdout,'data');
  await ready;
  const host={...systemProcessOwnershipHost,environment:async(pid,...rest)=>{
    const value=await systemProcessOwnershipHost.environment(pid,...rest);
    if(value.REA_PROCESS_RUN_ID===undefined){
      const stat=await readFile(`/proc/${pid}/stat`,'utf8').catch(()=>null);
      observations.push({pid,postReadState:stat===null?'absent':stat.slice(stat.lastIndexOf(')')+2).split(' ')[0]});
    }
    return value;
  }};
  const acknowledged=once(child.stdout,'data');
  child.stdin.end('exit');
  await acknowledged;
  const first=await cleanupOwnedProcessGroup(spawned.ownership,host);
  await exit;
  const afterExit=await cleanupOwnedProcessGroup(spawned.ownership,host);
  if(!afterExit.cleaned)throw new Error('Owned group still unconfirmed after observed exit: '+JSON.stringify(afterExit));
  results.push({first,observations,afterExit});
}
console.log(JSON.stringify({attempts:results.length,firstIncomplete:results.filter(x=>!x.first.cleaned).length,results},null,2));

Run from the source checkout root on Linux with Node24.18.0 and ps available: node repro.mjs. Output is a JSON ledger. The actual run mounted compiled source read-only into node:24.18.0-bookworm-slim with Docker init and installed procps from cached, signed-index Debian packages; no GitHub credentials were mounted or passed into children.

Expected behavior

When ownership becomes unreadable because a captured process has exited, retain that uncertainty and confirm liveness before reporting a live foreign-token mismatch. Existing live foreign-process, missing/mismatched-token and unreadable-identity cases must still fail closed; this report does not propose ignoring mismatches or signaling based only on PID.

Impact and scope

Intermittent cleanup failures can retain a runtime root/lease and fail tests until cleanup retry. This was investigated following the unrelated reconstruction fix #3802: its first local full coverage retry failed binarySessionCleanupRetry.test.ts with this symptom and secondary ENOTEMPTY. The original evaluator baseline also reproduced the Hopper failure in a diagnostic50-repeat copy (84pass/16fail across100cases). A process-boundary diagnostic run saw the same mismatch in Jadx cleanup, while Hopper passed that time. These are fixture/boundary observations, not real Hopper/Jadx engine verification.

Formal priority: not triaged. Other OS/architectures and real engines: NOT_ENOUGH_INFO, not tested for this race. No unauthorized signaling was observed; the failure remained conservative.

REA version

Source 9315aa6698bcf5d595978a375c5f2ac299081185, incorporating upstream 1bd5c5c87e81b27bfb16140f71ffa03563e58477. The process ownership implementation is unchanged by #3802.

Runtime and platform

Node24.18.0; Linux arm64; Debian bookworm container; procps; Docker --init. HOME is the container account home, SHLVL=1. No real engine required.

Target and artifact context

Source-owned, short-lived Node child processes only.

Interface

Other — compiled production process-ownership API and existing boundary tests.

Earliest failure stage

Cleanup, cancellation, or lifecycle.

Relevant output or evidence

{"attempts":100,"firstIncomplete":6}
{"first":{"cleaned":false,"reason":"process ownership token mismatch for PID(s): 473","failures":[{"pid":473,"reason":"run-token-mismatch"}]},"observations":[{"pid":473,"postReadState":"Z"}],"afterExit":{"cleaned":true,"signaled":false}}
{"first":{"cleaned":false,"reason":"process ownership token mismatch for PID(s): 539","failures":[{"pid":539,"reason":"run-token-mismatch"}]},"observations":[{"pid":539,"postReadState":"absent"}],"afterExit":{"cleaned":true,"signaled":false}}

Analysis or suspected cause

Source-derived: Linux createSystemProcessOwnershipHost.environment parses /proc/PID/environ; readProcessRunTokens projects the missing key as state:readable, runId:undefined. processRunTokenFailures classifies that as mismatch. recheckOwnershipFailures intentionally never clears readable mismatches and only rechecks unreadable/identity failures. liveProcesses already filters zombies at snapshot time (#233); an exit between that snapshot and the token read is a distinct interleaving. The observations support this path, but a production correction and its negative controls have not been implemented or verified. A change should preserve the intended live-foreign-token protection.

AI-assisted reproduction/report. Original failed logs and passing controls retained; no production change is claimed.

Related lifecycle audit: #4227. Distinct from #4282, which reports token visibility on still-live Chromium processes; this reduced case uses a Node process that is exiting. Related #233 already filters zombies present in the initial snapshot. Current #4274 does not change the process token-read/recheck boundary in this reproduction.

Originally created by @SII-YDD on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4322 ### Before submitting - [x] Searched open/closed issues and PRs for `environ cleanup`, `token mismatch`, and `empty environment`. - [x] No credentials, complete environment contents, or private targets are included. ### Area Process capture or runtime observation ### Observed behavior An owned Node child that acknowledges shutdown and then exits naturally can make `cleanupOwnedProcessGroup` return `cleaned:false` with `process ownership token mismatch`. A fresh observation at the missing-token read finds that PID already zombie or absent. After the actual child exit event, a cleanup retry succeeds without signaling anything. Observed in an isolated Linux arm64 container using actual Node processes, independent of Hopper/Jadx. One bounded100-case diagnostic run produced6 initial failures; every one of the100 post-exit retries reported cleaned. These counts describe this run, not an estimated failure probability. ### Reproduction Build the source (`npm ci`, `npm run build:cached`). The attached reduced reproducer uses the compiled production modules and starts100 source-owned Node children, each with an exact run token via `spawnOwnedProviderProcess`. Each child writes `ready`, acknowledges a stdin shutdown request, then exits after1..5ms. Immediately after the acknowledgement, call `cleanupOwnedProcessGroup`; record a fresh `/proc/PID/stat` state only when the production environment reader returns no run token. Join the exit event and call cleanup again. All children are joined and all groups are verified cleaned. A100-case immediate-cleanup control without acknowledgement/delayed exit had0 failures. The acknowledgement/exit interleaving exposes the issue; no test retries, skip, assertion, timeout or ownership policy was changed. Full executable script follows. ```js import { readFile } from 'node:fs/promises'; import { once } from 'node:events'; import { spawnOwnedProviderProcess } from './dist/process/ProviderProcess.js'; import { cleanupOwnedProcessGroup } from './dist/process/ProcessOwnership.js'; import { systemProcessOwnershipHost } from './dist/process/ProcessOwnershipObservation.js'; const results=[]; for(let i=0;i<100;i++) { const observations=[]; const spawned=await spawnOwnedProviderProcess({command:process.execPath,arguments:['-e','process.stdin.once("data",()=>{process.stdout.write("ack"); setTimeout(()=>process.exit(0),Number(process.argv[1]));}); process.stdout.write("ready");',String(1+i%5)],runId:`rea-ci-20261016-${i}`,expectedCommand:null,stdin:'pipe'}); const child=spawned.process; const exit=once(child,'exit'); const ready=once(child.stdout,'data'); await ready; const host={...systemProcessOwnershipHost,environment:async(pid,...rest)=>{ const value=await systemProcessOwnershipHost.environment(pid,...rest); if(value.REA_PROCESS_RUN_ID===undefined){ const stat=await readFile(`/proc/${pid}/stat`,'utf8').catch(()=>null); observations.push({pid,postReadState:stat===null?'absent':stat.slice(stat.lastIndexOf(')')+2).split(' ')[0]}); } return value; }}; const acknowledged=once(child.stdout,'data'); child.stdin.end('exit'); await acknowledged; const first=await cleanupOwnedProcessGroup(spawned.ownership,host); await exit; const afterExit=await cleanupOwnedProcessGroup(spawned.ownership,host); if(!afterExit.cleaned)throw new Error('Owned group still unconfirmed after observed exit: '+JSON.stringify(afterExit)); results.push({first,observations,afterExit}); } console.log(JSON.stringify({attempts:results.length,firstIncomplete:results.filter(x=>!x.first.cleaned).length,results},null,2)); ``` Run from the source checkout root on Linux with Node24.18.0 and `ps` available: `node repro.mjs`. Output is a JSON ledger. The actual run mounted compiled source read-only into `node:24.18.0-bookworm-slim` with Docker init and installed `procps` from cached, signed-index Debian packages; no GitHub credentials were mounted or passed into children. ### Expected behavior When ownership becomes unreadable because a captured process has exited, retain that uncertainty and confirm liveness before reporting a live foreign-token mismatch. Existing live foreign-process, missing/mismatched-token and unreadable-identity cases must still fail closed; this report does not propose ignoring mismatches or signaling based only on PID. ### Impact and scope Intermittent cleanup failures can retain a runtime root/lease and fail tests until cleanup retry. This was investigated following the unrelated reconstruction fix #3802: its first local full coverage retry failed `binarySessionCleanupRetry.test.ts` with this symptom and secondary ENOTEMPTY. The original evaluator baseline also reproduced the Hopper failure in a diagnostic50-repeat copy (84pass/16fail across100cases). A process-boundary diagnostic run saw the same mismatch in Jadx cleanup, while Hopper passed that time. These are fixture/boundary observations, not real Hopper/Jadx engine verification. Formal priority: **not triaged**. Other OS/architectures and real engines: **NOT_ENOUGH_INFO**, not tested for this race. No unauthorized signaling was observed; the failure remained conservative. ### REA version Source `9315aa6698bcf5d595978a375c5f2ac299081185`, incorporating upstream `1bd5c5c87e81b27bfb16140f71ffa03563e58477`. The process ownership implementation is unchanged by #3802. ### Runtime and platform Node24.18.0; Linux arm64; Debian bookworm container; procps; Docker `--init`. HOME is the container account home, SHLVL=1. No real engine required. ### Target and artifact context Source-owned, short-lived Node child processes only. ### Interface Other — compiled production process-ownership API and existing boundary tests. ### Earliest failure stage Cleanup, cancellation, or lifecycle. ### Relevant output or evidence ```json {"attempts":100,"firstIncomplete":6} {"first":{"cleaned":false,"reason":"process ownership token mismatch for PID(s): 473","failures":[{"pid":473,"reason":"run-token-mismatch"}]},"observations":[{"pid":473,"postReadState":"Z"}],"afterExit":{"cleaned":true,"signaled":false}} {"first":{"cleaned":false,"reason":"process ownership token mismatch for PID(s): 539","failures":[{"pid":539,"reason":"run-token-mismatch"}]},"observations":[{"pid":539,"postReadState":"absent"}],"afterExit":{"cleaned":true,"signaled":false}} ``` ### Analysis or suspected cause Source-derived: Linux `createSystemProcessOwnershipHost.environment` parses `/proc/PID/environ`; `readProcessRunTokens` projects the missing key as `state:readable, runId:undefined`. `processRunTokenFailures` classifies that as mismatch. `recheckOwnershipFailures` intentionally never clears readable mismatches and only rechecks unreadable/identity failures. `liveProcesses` already filters zombies at snapshot time (#233); an exit between that snapshot and the token read is a distinct interleaving. The observations support this path, but a production correction and its negative controls have **not** been implemented or verified. A change should preserve the intended live-foreign-token protection. AI-assisted reproduction/report. Original failed logs and passing controls retained; no production change is claimed. Related lifecycle audit: #4227. Distinct from #4282, which reports token visibility on still-live Chromium processes; this reduced case uses a Node process that is exiting. Related #233 already filters zombies present in the initial snapshot. Current #4274 does not change the process token-read/recheck boundary in this reproduction.

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

@Jackzigen commented on GitHub (Oct 16, 2026):

Confirmed against the current implementation: on Linux an owned child that has exited but not yet been reaped still yields a readable-but-empty /proc/<pid>/environ, which classifies as run-token-mismatch rather than environment-unreadable. recheckOwnershipFailures then early-returns for a mismatch-only failure set, so the fresh process-table liveness check never runs for exactly the case that needs it — a zombie PID is no longer in the live table and would have been cleared. That matches the reproducer's 6/100 first-cleanup failures with all 100 post-exit retries clean.

I'd like to take this one. Planned direction: run the liveness recheck for mismatch failures too, and clear any failure whose PID is absent from the fresh live table (a still-live mismatch keeps failing closed; a recheck error still retains everything). Regression test using the ack-then-exit interleaving from the reproducer. PR to follow.

@Jackzigen commented on GitHub (Oct 16, 2026): Confirmed against the current implementation: on Linux an owned child that has exited but not yet been reaped still yields a readable-but-empty `/proc/<pid>/environ`, which classifies as `run-token-mismatch` rather than `environment-unreadable`. `recheckOwnershipFailures` then early-returns for a mismatch-only failure set, so the fresh process-table liveness check never runs for exactly the case that needs it — a zombie PID is no longer in the live table and would have been cleared. That matches the reproducer's 6/100 first-cleanup failures with all 100 post-exit retries clean. I'd like to take this one. Planned direction: run the liveness recheck for mismatch failures too, and clear any failure whose PID is absent from the fresh live table (a still-live mismatch keeps failing closed; a recheck error still retains everything). Regression test using the ack-then-exit interleaving from the reproducer. PR to follow.

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

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

The reproducer is convincing — the acknowledgement/exit interleaving is exactly the window where the token read races the process teardown, and the 100-case retry-always-cleans result confirms it is transient rather than a real ownership mismatch. A couple of directions that might make cleanupOwnedProcessGroup more robust without changing ownership policy: (1) when the environment reader finds no run token, first check whether the PID is already zombie/absent and treat that as an effectively-cleaned group instead of reporting a mismatch; (2) alternatively, treat a missing token as "recheck once after the child exit event" rather than an immediate failure, since the exit event is already joinable at that point. Would be good to also cover the delayed-exit range (e.g. 0.5–10ms) in the CI regression test to keep the race window pinned.

@XinwangTao commented on GitHub (Oct 16, 2026): The reproducer is convincing — the acknowledgement/exit interleaving is exactly the window where the token read races the process teardown, and the 100-case retry-always-cleans result confirms it is transient rather than a real ownership mismatch. A couple of directions that might make cleanupOwnedProcessGroup more robust without changing ownership policy: (1) when the environment reader finds no run token, first check whether the PID is already zombie/absent and treat that as an effectively-cleaned group instead of reporting a mismatch; (2) alternatively, treat a missing token as "recheck once after the child exit event" rather than an immediate failure, since the exit event is already joinable at that point. Would be good to also cover the delayed-exit range (e.g. 0.5–10ms) in the CI regression test to keep the race window pinned.

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

@Jackzigen commented on GitHub (Oct 16, 2026):

Thanks for the analysis — the delayed-exit range in the regression test is a good point, but race-pinning with real timing would be flaky in CI; the two deterministic regressions in this PR instead pin the interleaving itself: first snapshot lists PID 101, the fresh liveness table after the token phase no longer shows it. That fixes the race window without a sleep-based test.

The fix distinguishes absent-token reads (exit artifact, clearable by a fresh liveness table) from readable foreign tokens (never cleared). Ownership policy is unchanged.

PR incoming on branch fix/ownership-mismatch-liveness-recheck — will link it here once opened (the GitHub API POST /pulls keeps 404-ing from my environment, so opening from the web compare view).

@Jackzigen commented on GitHub (Oct 16, 2026): Thanks for the analysis — the delayed-exit range in the regression test is a good point, but race-pinning with real timing would be flaky in CI; the two deterministic regressions in this PR instead pin the interleaving itself: first snapshot lists PID 101, the fresh liveness table after the token phase no longer shows it. That fixes the race window without a sleep-based test. The fix distinguishes absent-token reads (exit artifact, clearable by a fresh liveness table) from readable foreign tokens (never cleared). Ownership policy is unchanged. PR incoming on branch `fix/ownership-mismatch-liveness-recheck` — will link it here once opened (the GitHub API POST /pulls keeps 404-ing from my environment, so opening from the web compare view).

bsakaguchi commented

2026-10-16 21:09:25 +00:00

Author

Owner

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

Good call on the deterministic regressions — pinning the snapshot/liveness interleaving directly is much more robust than a sleep-based race-pin, which would just flake in CI. And keeping absent-token (clearable via the fresh liveness table) distinct from readable foreign tokens preserves the fail-closed behavior we need. Looking forward to the PR.

@XinwangTao commented on GitHub (Oct 16, 2026): Good call on the deterministic regressions — pinning the snapshot/liveness interleaving directly is much more robust than a sleep-based race-pin, which would just flake in CI. And keeping absent-token (clearable via the fresh liveness table) distinct from readable foreign tokens preserves the fail-closed behavior we need. Looking forward to the PR.

bsakaguchi commented

2026-10-31 00:32:19 +00:00

Author

Owner

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

49e67aa1d corrects the native lifetime boundary: ownership checks keep start identity, current parent/group relation, lifecycle, and token observations separate. A token disappearing while the native after-observation proves zombie/absence no longer becomes a live token mismatch; a live missing token and an unavailable identity still fail closed. Linux procfs ENOENT/ESRCH requires a corroborating signal-zero ESRCH before recording caller-namespace absence.

The four controlled Linux-host cases were run on macOS: zombie and absence clean without signaling; live missing-token and unreadable-identity cases remain failures. Actual Darwin helper compilation, owned-child cleanup, and public CLI/MCP capture controls passed. Static checks, docs checks, and discovery passed too.

Keeping this issue open: I have not rerun the original real-Linux 100-case reproduction, native Linux PID-reuse/exec timing, or Windows cleanup. The controlled host cases do not establish those runtime results.

@morluto commented on GitHub (Oct 19, 2026): [49e67aa1d](https://github.com/morluto/rea/commit/49e67aa1d963bda337c261f4813ecb7128e2a50c) corrects the native lifetime boundary: ownership checks keep start identity, current parent/group relation, lifecycle, and token observations separate. A token disappearing while the native after-observation proves zombie/absence no longer becomes a live token mismatch; a live missing token and an unavailable identity still fail closed. Linux procfs ENOENT/ESRCH requires a corroborating signal-zero ESRCH before recording caller-namespace absence. The four controlled Linux-host cases were run on macOS: zombie and absence clean without signaling; live missing-token and unreadable-identity cases remain failures. Actual Darwin helper compilation, owned-child cleanup, and public CLI/MCP capture controls passed. Static checks, docs checks, and discovery passed too. Keeping this issue open: I have not rerun the original real-Linux 100-case reproduction, native Linux PID-reuse/exec timing, or Windows cleanup. The controlled host cases do not establish those runtime results.

bsakaguchi commented

2026-10-31 00:32:19 +00:00

Author

Owner

@gensokyo-dev commented on GitHub (Oct 19, 2026):

Additional real Linux x86-64 evidence after 49e67aa1d (related to the native cleanup validation left open here): successful static-provider processes can still leave CLI/MCP reporting cleanup_incomplete.

Clean pre-#5171 main dc936f433 and merged main 3ea0d9489 were built independently with Node 24.18.0 / npm 11.16.0, GNU objdump 2.40 on Debian Linux. No source changes or target execution were used.
On both revisions, the original operation node scripts/rea.mjs inspect-with-objdump /usr/bin/true file_headers --json (no symbol) was captured exiting 1 with code: cleanup_incomplete. Retained native output reports exit 0, 151 stdout bytes, no stderr, and is byte-identical to independent objdump -f /usr/bin/true. Parent reports process identity could not be revalidated; merged main reports a live token read unavailable with environment_errno_EACCES=1.
This is intermittent: an earlier standalone parent CLI control passed. A separate 3-pair alternating run had 2/3 nonzero CLI exits on the parent and 3/3 on merged main; those are observed trials, not failure-rate estimates. The original receipts and passing control are retained.
Clean parent dc936f433 also fails all 4 existing tests across tests/boundary/mcp/reverseEngineeringEnvironmentMcp.test.ts and reverseEngineeringProviderEnvironmentMcp.test.ts with provider cleanup failures. These tests use provider fixtures, not a real Rizin installation. Reproduce: npm run test:focused -- tests/boundary/mcp/reverseEngineeringEnvironmentMcp.test.ts tests/boundary/mcp/reverseEngineeringProviderEnvironmentMcp.test.ts.
On merged main, a 30-file targeted run had 306 passed, 16 failed, 2 skipped; failures cover those environment cases, capture cancellation/progress and snapshot cleanup. Actual packaged MCP selected zlib disassembly also returned cleanup_incomplete after native exit 0 and the correct 405-byte output; partial Evidence remained retained. This is not counted as successful post-merge provider verification.

#5171's final head a4e3aa6ed with main 0fc8462be had 293 passing targeted tests (2 skipped) plus real CLI/MCP checks and fully green required CI. Main subsequently integrated 49e67aa1d / dc936f433 before the squash merge. The nine feature files are identical, and the parent reproduction above requires neither the feature nor its symbol option. This establishes an independent shared-cleanup problem; the precise native interleaving/root cause has not been localized, and these observations do not establish that every failure has the same cause as the original ARM64 reproducer.

All probes ran sequentially under one CPU with a hard cap no higher than 8 GiB (2 GiB for public probes), no observed OOM kills. The cgroup observer verified the launched process families had exited; that OS-level check does not replace the application's incomplete ownership/resource-cleanup result. Failed runs and retained cleanup evidence were preserved. No permission/token check was weakened and no unrelated fix was added to #5171.

@gensokyo-dev commented on GitHub (Oct 19, 2026): Additional **real Linux x86-64** evidence after `49e67aa1d` (related to the native cleanup validation left open here): successful static-provider processes can still leave CLI/MCP reporting `cleanup_incomplete`. - Clean pre-#5171 main `dc936f433` and merged main `3ea0d9489` were built independently with Node 24.18.0 / npm 11.16.0, GNU objdump 2.40 on Debian Linux. No source changes or target execution were used. - On **both** revisions, the original operation `node scripts/rea.mjs inspect-with-objdump /usr/bin/true file_headers --json` (no `symbol`) was captured exiting 1 with `code: cleanup_incomplete`. Retained native output reports **exit 0, 151 stdout bytes, no stderr**, and is byte-identical to independent `objdump -f /usr/bin/true`. Parent reports `process identity could not be revalidated`; merged main reports a live token read unavailable with `environment_errno_EACCES=1`. - This is intermittent: an earlier standalone parent CLI control passed. A separate 3-pair alternating run had 2/3 nonzero CLI exits on the parent and 3/3 on merged main; those are observed trials, not failure-rate estimates. The original receipts and passing control are retained. - Clean parent `dc936f433` also fails all 4 existing tests across `tests/boundary/mcp/reverseEngineeringEnvironmentMcp.test.ts` and `reverseEngineeringProviderEnvironmentMcp.test.ts` with provider cleanup failures. These tests use provider fixtures, not a real Rizin installation. Reproduce: `npm run test:focused -- tests/boundary/mcp/reverseEngineeringEnvironmentMcp.test.ts tests/boundary/mcp/reverseEngineeringProviderEnvironmentMcp.test.ts`. - On merged main, a 30-file targeted run had **306 passed, 16 failed, 2 skipped**; failures cover those environment cases, capture cancellation/progress and snapshot cleanup. Actual packaged MCP selected zlib disassembly also returned `cleanup_incomplete` after native exit 0 and the correct 405-byte output; partial Evidence remained retained. This is not counted as successful post-merge provider verification. #5171's final head `a4e3aa6ed` with main `0fc8462be` had 293 passing targeted tests (2 skipped) plus real CLI/MCP checks and fully green required CI. Main subsequently integrated `49e67aa1d` / `dc936f433` before the squash merge. The nine feature files are identical, and the parent reproduction above requires neither the feature nor its symbol option. This establishes an independent shared-cleanup problem; the precise native interleaving/root cause has **not** been localized, and these observations do not establish that every failure has the same cause as the original ARM64 reproducer. All probes ran sequentially under one CPU with a hard cap no higher than 8 GiB (2 GiB for public probes), no observed OOM kills. The cgroup observer verified the launched process families had exited; that OS-level check does not replace the application's incomplete ownership/resource-cleanup result. Failed runs and retained cleanup evidence were preserved. No permission/token check was weakened and no unrelated fix was added to #5171.

bsakaguchi commented

2026-10-31 00:32:19 +00:00

Author

Owner

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

Thanks for the extra real-Linux evidence — it makes clear 49e67aa fixed the token-mismatch path but not every cleanup_incomplete surface: a successful native exit with byte-identical output still leaking into cleanup_incomplete points at the shared cleanup path needing a separate look. The follow-ups referenced here (#5252 zombie sweeps, #5270 unresolved descendants, #5277 detached short-lived inferior) look like the right places to chase it — #5277 in particular matches the original ack-then-exit interleaving closely. It would be valuable to check whether the remaining real-Linux failures overlap with those fixes once they land.

@XinwangTao commented on GitHub (Oct 20, 2026): Thanks for the extra real-Linux evidence — it makes clear 49e67aa fixed the token-mismatch path but not every cleanup_incomplete surface: a successful native exit with byte-identical output still leaking into cleanup_incomplete points at the shared cleanup path needing a separate look. The follow-ups referenced here (#5252 zombie sweeps, #5270 unresolved descendants, #5277 detached short-lived inferior) look like the right places to chase it — #5277 in particular matches the original ack-then-exit interleaving closely. It would be valuable to check whether the remaining real-Linux failures overlap with those fixes once they land.

bsakaguchi referenced this issue

2026-10-31 00:34:58 +00:00

[GH-ISSUE #4856] [Bug] TOML client setup and uninstall fail on valid documents with many preserved lines #3019

bsakaguchi referenced this issue

2026-10-31 00:54:57 +00:00

[PR #1717] [CLOSED] feat(setup): add Maki client support #4778