morluto/rea

Fork 0

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

[GH-ISSUE #4011] [Bug] Recorded-crash debugger cleanup rejects its owned GDB after launcher exec #1596

New issue

Closed

opened 2026-10-16 21:07:40 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-16 21:07:40 +00:00

Owner

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

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

Source-derived defect, supported by an executed simulated-provider test: the optional recorded-crash debugger stage starts Python, deliberately execs GDB, then rejects that correctly owned live process during cancellation because ownership still expects Python. The simulated production-setting case returned ProviderAdapterError with cleanupIncomplete: true, reported owned launcher command identity did not match, and sent no stop signal. A control that removed only the stale command expectation stopped the same simulated process and returned ordinary AnalysisCancelledError.

No real Python core decoder, GDB or pwndbg process was launched. A public CLI/MCP runtime reproduction was not run.

Reproduction

The executed focused test called the real RecordedCrashService, PwntoolsRecordedCrashProvider, inspectPwndbgCore, supervisor and ownership cleanup. It injected a valid source-owned core fixture reply, then a launcher/process table with the configured debugger command, matching parent, process group and run token. The test selected Linux x64 host fields inside the isolated test and restored them afterward. Both cases passed as assertions of the defect and its discriminating control.

With the baseline checkout and locked dependencies prepared, save this test as tests/process-global/recordedCrashDebuggerCancellation.test.ts and run:

export REA_REPRO_SCRATCH="$(mktemp -d)"
npx --no-install vitest run tests/process-global/recordedCrashDebuggerCancellation.test.ts

Executed production-boundary test

import {EventEmitter} from 'node:events';
import {PassThrough} from 'node:stream';
import {mkdir,writeFile,readFile,rm} from 'node:fs/promises';
import {join} from 'node:path';
import {expect,it} from 'vitest';
import {z} from 'zod';
import {PwntoolsRecordedCrashProvider} from '../../src/native/pwntools/PwntoolsRecordedCrashProvider.js';
import {RecordedCrashService} from '../../src/application/binaryDiagnostics/RecordedCrashService.js';
import {cleanupOwnedProcessGroup} from '../../src/process/ProcessOwnership.js';
import {PWNTOOLS_PROVIDER_IDENTITY} from '../../src/native/pwntools/PwntoolsRelease.js';
import {recordedCrashFixture,recordedCrashFixtureBytes} from '../fixtures/binaryDiagnostics/recordedCrash.js';

it.each([false,true])('recorded-crash debugger cancellation after exec, relaxed command = %s',async(relaxCommand)=>{
 const root=join(process.env.REA_REPRO_SCRATCH!, relaxCommand?'control':'original');
 await mkdir(root,{recursive:true});
 const file=join(root,'sample.core'); const report=recordedCrashFixture(file);
 await writeFile(file,recordedCrashFixtureBytes(report));
 await writeFile(join(root,'gdb'),'',{mode:0o700}); await writeFile(join(root,'gdbinit.py'),''); await mkdir(join(root,'venv'),{recursive:true});
 const controller=new AbortController(); const originalPlatform=Object.getOwnPropertyDescriptor(process,'platform')!;
 const originalArch=Object.getOwnPropertyDescriptor(process,'arch')!;
 const signals:string[]=[]; let liveDebugger=false; let rounds=0; let forceExit=()=>{};
 class Child extends EventEmitter {
  readonly pid=41234; readonly stdout=new PassThrough(); readonly stderr=new PassThrough();
  exitCode:number|null=null; signalCode:NodeJS.Signals|null=null;
  kill(){throw new Error('must validate ownership');}
 }
 const {artifact:_a,diagnostics:_d,debugger:_g,decoder_diagnostics:_dd,...payload}=report;
 const provider=new PwntoolsRecordedCrashProvider({REA_PWNTOOLS_PYTHON:process.execPath,REA_PWNDBG_GDB:join(root,'gdb'),REA_PWNDBG_GDBINIT:join(root,'gdbinit.py'),REA_PWNDBG_VENV_PATH:join(root,'venv')},async spawn=>{
  const basic=rounds++===0; const child=new Child(); let live=true;
  const finish=()=>{live=false;if(!basic)liveDebugger=false;child.exitCode=0;child.stdout.end();child.stderr.end();child.emit('exit',0,null);child.emit('close',0,null);};
  const request=z.object({reply_path:z.string()}).parse(JSON.parse(await readFile(spawn.arguments.at(-1)!,'utf8')));
  if(basic){await writeFile(request.reply_path,JSON.stringify({ok:true,profile:PWNTOOLS_PROVIDER_IDENTITY.version,value:payload}));setImmediate(finish);}
  else {liveDebugger=true;forceExit=finish;setImmediate(()=>controller.abort());}
  const ownership={runId:spawn.runId,leaderPid:child.pid,processGroupId:child.pid,expectedParentPid:process.pid,...((!basic&&relaxCommand)||spawn.expectedCommand===null?{}:{expectedCommand:spawn.expectedCommand??spawn.command})};
  return {process:child,ownership,cleanup:()=>cleanupOwnedProcessGroup(ownership,{
   listProcesses:async()=>live?[{pid:child.pid,parentPid:process.pid,processGroupId:child.pid,state:'S',command:basic?`${spawn.command} -I core.py`:`${join(root,'gdb')} -nx -nh --batch --quiet`}]:[],
   environment:async()=>({REA_PROCESS_RUN_ID:spawn.runId}),signalGroup:(_pid,signal)=>{signals.push(signal);finish();}
  })};
 },async()=>{const path=join(root,'runtime');await mkdir(path);return {path,close:()=>rm(path,{recursive:true})};});
 try {
  Object.defineProperty(process,'platform',{value:'linux'});Object.defineProperty(process,'arch',{value:'x64'});
  const result=await new RecordedCrashService(provider).inspectAndClose({path:file,include_debugger_context:true},{signal:controller.signal});
  console.log(JSON.stringify({relaxCommand,ok:result.ok,liveDebugger,signals,rounds,errorTag:result.ok?null:result.error._tag,cleanupIncomplete:result.ok?null:result.error.cleanupIncomplete,identityMismatch:!result.ok&&JSON.stringify(result.error).includes('owned launcher command identity did not match')}));
  expect(rounds).toBe(2);expect(result.ok).toBe(false);expect(liveDebugger).toBe(!relaxCommand);expect(signals).toHaveLength(relaxCommand?1:0);
  if(result.ok)throw new Error('expected cancellation');expect(result.error.cleanupIncomplete).toBe(!relaxCommand);
 } finally {forceExit();await provider.close();Object.defineProperty(process,'platform',originalPlatform);Object.defineProperty(process,'arch',originalArch);}
});

The test retires the fake debugger before teardown. The production trigger established by source, but not executed here, is node scripts/rea.mjs inspect-recorded-crash CORE --debugger-context --json on the documented Linux host with configured engine paths and a valid supported core, followed by cancellation while GDB remains live after exec.

Expected behavior

Optional debugger mapping context documents that the owned Python launcher replaces itself with GDB and that the outer provider owns both processes. Bounds and verification makes cancellation and independent owned cleanup explicit. Cleanup must recognize the configured debugger after deliberate exec and retire it on cancellation while preserving parent, process-group and run-token validation.

Impact and scope

The defect affects cancellation during optional debugger enrichment while the owned debugger remains live. The simulation proves the ownership mismatch and missed signal, but does not establish real-engine persistence duration, resource use or occurrence frequency. Waiting for natural debugger exit is an unverified workaround. Omitting debugger context avoids the stage but does not preserve the requested optional result.

REA version

rea 6.5.0 at source commit 4692bb3330; unchanged failing code checked by source at origin/main 6fcfc5b5e0

Runtime and platform

Node 24.18.0; macOS arm64; Vitest 5.0.3. Test used a simulated launcher/process table and selected Linux x64 fields. The documented production context is Linux x64 with the configured pwntools profile and optional GDB/pwndbg.

Target and artifact context

Source-owned recorded-crash fixture with simulated decoder output and debugger process identity. No real core decoder or debugger engine was exercised.

Interface

Other

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Meaningful output from both executed simulated-provider cases:

{"relaxCommand":false,"ok":false,"liveDebugger":true,"signals":[],"rounds":2,"errorTag":"ProviderAdapterError","cleanupIncomplete":true,"identityMismatch":true}
{"relaxCommand":true,"ok":false,"liveDebugger":false,"signals":["SIGKILL"],"rounds":2,"errorTag":"AnalysisCancelledError","cleanupIncomplete":false,"identityMismatch":false}

relaxCommand=false preserves production ownership settings. The control changes only the obsolete expected-command setting for the optional debugger stage; matching parent, process-group and run-token checks remain enabled.

Source reachability: src/cli/binaryDiagnosticsCommands.ts and src/composition/binaryDiagnostics.ts reach RecordedCrashService.inspectAndClose, PwntoolsDecoder.#inspect, and PwntoolsRecordedCrashProvider's include_debugger_context branch. The MCP contract is registered in src/server/registerRecordedCrashTools.ts. After host, regular core, size/profile and basic decoder admission, absolute readable plugin/venv paths and executable GDB reach inspectPwndbgCore.

All cited failing source files and the recorded-crash documentation are unchanged between the baseline and current origin/main revision above. This was a source freshness check, not a new runtime execution.

Typed outcome or recovery expected

Cancellation should stop the admitted, correctly owned debugger and retain cancellation as the primary result with completed cleanup. Proposed restoration checks should preserve recorded evidence and permit runtime-root retirement, with wrong-parent, wrong-group and wrong-token controls. A real Linux GDB/pwndbg cancellation run would additionally establish engine timing and process-table presentation.

Analysis or suspected cause

Source-derived chain:

src/native/pwndbg/PwndbgCoreContext.ts:148-174 constructs the Python spawn without an exec-aware command expectation.
bridge/pwndbg/launch_impl.py:26 calls os.execve with the configured GDB.
src/process/ProviderProcess.ts:259-261 defaults the ownership command to the original Python executable.
src/process/ProcessOwnershipIdentity.ts:19-23 rejects that changed command. settleLauncherExit in src/process/ProcessOwnership.ts retains the rejection when a refreshed process table still contains the debugger, before signaling.

The basic decoder separately uses expectedCommand: null in src/native/pwntools/PwntoolsDecoder.ts:304 to accommodate launcher exec transitions. That setting does not propagate to the independently constructed optional stage.

Additional context

Closed #3337 reports a related ownership-command mismatch for Apktool shell launchers. This report concerns the separate recorded-crash optional debugger spawn and its deliberate Python-to-GDB exec; that path still retains Python as its expected command on current main. Open PR #1959 adds shared debugger session shutdown helpers and does not modify this optional stage or its command identity. No last known good version is established.

Originally created by @coygeek on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4011 ### 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 Source-derived defect, supported by an executed simulated-provider test: the optional recorded-crash debugger stage starts Python, deliberately execs GDB, then rejects that correctly owned live process during cancellation because ownership still expects Python. The simulated production-setting case returned `ProviderAdapterError` with `cleanupIncomplete: true`, reported `owned launcher command identity did not match`, and sent no stop signal. A control that removed only the stale command expectation stopped the same simulated process and returned ordinary `AnalysisCancelledError`. No real Python core decoder, GDB or pwndbg process was launched. A public CLI/MCP runtime reproduction was not run. ### Reproduction The executed focused test called the real `RecordedCrashService`, `PwntoolsRecordedCrashProvider`, `inspectPwndbgCore`, supervisor and ownership cleanup. It injected a valid source-owned core fixture reply, then a launcher/process table with the configured debugger command, matching parent, process group and run token. The test selected Linux x64 host fields inside the isolated test and restored them afterward. Both cases passed as assertions of the defect and its discriminating control. With the baseline checkout and locked dependencies prepared, save this test as `tests/process-global/recordedCrashDebuggerCancellation.test.ts` and run: ```sh export REA_REPRO_SCRATCH="$(mktemp -d)" npx --no-install vitest run tests/process-global/recordedCrashDebuggerCancellation.test.ts ``` <details> <summary>Executed production-boundary test</summary> ```ts import {EventEmitter} from 'node:events'; import {PassThrough} from 'node:stream'; import {mkdir,writeFile,readFile,rm} from 'node:fs/promises'; import {join} from 'node:path'; import {expect,it} from 'vitest'; import {z} from 'zod'; import {PwntoolsRecordedCrashProvider} from '../../src/native/pwntools/PwntoolsRecordedCrashProvider.js'; import {RecordedCrashService} from '../../src/application/binaryDiagnostics/RecordedCrashService.js'; import {cleanupOwnedProcessGroup} from '../../src/process/ProcessOwnership.js'; import {PWNTOOLS_PROVIDER_IDENTITY} from '../../src/native/pwntools/PwntoolsRelease.js'; import {recordedCrashFixture,recordedCrashFixtureBytes} from '../fixtures/binaryDiagnostics/recordedCrash.js'; it.each([false,true])('recorded-crash debugger cancellation after exec, relaxed command = %s',async(relaxCommand)=>{ const root=join(process.env.REA_REPRO_SCRATCH!, relaxCommand?'control':'original'); await mkdir(root,{recursive:true}); const file=join(root,'sample.core'); const report=recordedCrashFixture(file); await writeFile(file,recordedCrashFixtureBytes(report)); await writeFile(join(root,'gdb'),'',{mode:0o700}); await writeFile(join(root,'gdbinit.py'),''); await mkdir(join(root,'venv'),{recursive:true}); const controller=new AbortController(); const originalPlatform=Object.getOwnPropertyDescriptor(process,'platform')!; const originalArch=Object.getOwnPropertyDescriptor(process,'arch')!; const signals:string[]=[]; let liveDebugger=false; let rounds=0; let forceExit=()=>{}; class Child extends EventEmitter { readonly pid=41234; readonly stdout=new PassThrough(); readonly stderr=new PassThrough(); exitCode:number|null=null; signalCode:NodeJS.Signals|null=null; kill(){throw new Error('must validate ownership');} } const {artifact:_a,diagnostics:_d,debugger:_g,decoder_diagnostics:_dd,...payload}=report; const provider=new PwntoolsRecordedCrashProvider({REA_PWNTOOLS_PYTHON:process.execPath,REA_PWNDBG_GDB:join(root,'gdb'),REA_PWNDBG_GDBINIT:join(root,'gdbinit.py'),REA_PWNDBG_VENV_PATH:join(root,'venv')},async spawn=>{ const basic=rounds++===0; const child=new Child(); let live=true; const finish=()=>{live=false;if(!basic)liveDebugger=false;child.exitCode=0;child.stdout.end();child.stderr.end();child.emit('exit',0,null);child.emit('close',0,null);}; const request=z.object({reply_path:z.string()}).parse(JSON.parse(await readFile(spawn.arguments.at(-1)!,'utf8'))); if(basic){await writeFile(request.reply_path,JSON.stringify({ok:true,profile:PWNTOOLS_PROVIDER_IDENTITY.version,value:payload}));setImmediate(finish);} else {liveDebugger=true;forceExit=finish;setImmediate(()=>controller.abort());} const ownership={runId:spawn.runId,leaderPid:child.pid,processGroupId:child.pid,expectedParentPid:process.pid,...((!basic&&relaxCommand)||spawn.expectedCommand===null?{}:{expectedCommand:spawn.expectedCommand??spawn.command})}; return {process:child,ownership,cleanup:()=>cleanupOwnedProcessGroup(ownership,{ listProcesses:async()=>live?[{pid:child.pid,parentPid:process.pid,processGroupId:child.pid,state:'S',command:basic?`${spawn.command} -I core.py`:`${join(root,'gdb')} -nx -nh --batch --quiet`}]:[], environment:async()=>({REA_PROCESS_RUN_ID:spawn.runId}),signalGroup:(_pid,signal)=>{signals.push(signal);finish();} })}; },async()=>{const path=join(root,'runtime');await mkdir(path);return {path,close:()=>rm(path,{recursive:true})};}); try { Object.defineProperty(process,'platform',{value:'linux'});Object.defineProperty(process,'arch',{value:'x64'}); const result=await new RecordedCrashService(provider).inspectAndClose({path:file,include_debugger_context:true},{signal:controller.signal}); console.log(JSON.stringify({relaxCommand,ok:result.ok,liveDebugger,signals,rounds,errorTag:result.ok?null:result.error._tag,cleanupIncomplete:result.ok?null:result.error.cleanupIncomplete,identityMismatch:!result.ok&&JSON.stringify(result.error).includes('owned launcher command identity did not match')})); expect(rounds).toBe(2);expect(result.ok).toBe(false);expect(liveDebugger).toBe(!relaxCommand);expect(signals).toHaveLength(relaxCommand?1:0); if(result.ok)throw new Error('expected cancellation');expect(result.error.cleanupIncomplete).toBe(!relaxCommand); } finally {forceExit();await provider.close();Object.defineProperty(process,'platform',originalPlatform);Object.defineProperty(process,'arch',originalArch);} }); ``` </details> The test retires the fake debugger before teardown. The production trigger established by source, but not executed here, is `node scripts/rea.mjs inspect-recorded-crash CORE --debugger-context --json` on the documented Linux host with configured engine paths and a valid supported core, followed by cancellation while GDB remains live after exec. ### Expected behavior [Optional debugger mapping context](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/docs/recorded-crashes.md#L44) documents that the owned Python launcher replaces itself with GDB and that the outer provider owns both processes. [Bounds and verification](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/docs/recorded-crashes.md#L75) makes cancellation and independent owned cleanup explicit. Cleanup must recognize the configured debugger after deliberate exec and retire it on cancellation while preserving parent, process-group and run-token validation. ### Impact and scope The defect affects cancellation during optional debugger enrichment while the owned debugger remains live. The simulation proves the ownership mismatch and missed signal, but does not establish real-engine persistence duration, resource use or occurrence frequency. Waiting for natural debugger exit is an unverified workaround. Omitting debugger context avoids the stage but does not preserve the requested optional result. ### REA version rea 6.5.0 at source commit 4692bb33300c7cb77b095b6cc0c33da861c1b860; unchanged failing code checked by source at origin/main 6fcfc5b5e0c063300cd5278dd8bad5b1ab1374f6 ### Runtime and platform Node 24.18.0; macOS arm64; Vitest 5.0.3. Test used a simulated launcher/process table and selected Linux x64 fields. The documented production context is Linux x64 with the configured pwntools profile and optional GDB/pwndbg. ### Target and artifact context Source-owned recorded-crash fixture with simulated decoder output and debugger process identity. No real core decoder or debugger engine was exercised. ### Interface Other ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Meaningful output from both executed simulated-provider cases: ```json {"relaxCommand":false,"ok":false,"liveDebugger":true,"signals":[],"rounds":2,"errorTag":"ProviderAdapterError","cleanupIncomplete":true,"identityMismatch":true} {"relaxCommand":true,"ok":false,"liveDebugger":false,"signals":["SIGKILL"],"rounds":2,"errorTag":"AnalysisCancelledError","cleanupIncomplete":false,"identityMismatch":false} ``` `relaxCommand=false` preserves production ownership settings. The control changes only the obsolete expected-command setting for the optional debugger stage; matching parent, process-group and run-token checks remain enabled. Source reachability: `src/cli/binaryDiagnosticsCommands.ts` and `src/composition/binaryDiagnostics.ts` reach `RecordedCrashService.inspectAndClose`, `PwntoolsDecoder.#inspect`, and `PwntoolsRecordedCrashProvider`'s `include_debugger_context` branch. The MCP contract is registered in `src/server/registerRecordedCrashTools.ts`. After host, regular core, size/profile and basic decoder admission, absolute readable plugin/venv paths and executable GDB reach `inspectPwndbgCore`. All cited failing source files and the recorded-crash documentation are unchanged between the baseline and current origin/main revision above. This was a source freshness check, not a new runtime execution. ### Typed outcome or recovery expected Cancellation should stop the admitted, correctly owned debugger and retain cancellation as the primary result with completed cleanup. Proposed restoration checks should preserve recorded evidence and permit runtime-root retirement, with wrong-parent, wrong-group and wrong-token controls. A real Linux GDB/pwndbg cancellation run would additionally establish engine timing and process-table presentation. ### Analysis or suspected cause Source-derived chain: - [`src/native/pwndbg/PwndbgCoreContext.ts:148-174`](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/src/native/pwndbg/PwndbgCoreContext.ts#L148) constructs the Python spawn without an exec-aware command expectation. - [`bridge/pwndbg/launch_impl.py:26`](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/bridge/pwndbg/launch_impl.py#L26) calls `os.execve` with the configured GDB. - [`src/process/ProviderProcess.ts:259-261`](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/src/process/ProviderProcess.ts#L259) defaults the ownership command to the original Python executable. - [`src/process/ProcessOwnershipIdentity.ts:19-23`](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/src/process/ProcessOwnershipIdentity.ts#L19) rejects that changed command. [`settleLauncherExit` in `src/process/ProcessOwnership.ts`](https://github.com/morluto/rea/blob/4692bb33300c7cb77b095b6cc0c33da861c1b860/src/process/ProcessOwnership.ts#L364) retains the rejection when a refreshed process table still contains the debugger, before signaling. The basic decoder separately uses `expectedCommand: null` in `src/native/pwntools/PwntoolsDecoder.ts:304` to accommodate launcher exec transitions. That setting does not propagate to the independently constructed optional stage. ### Additional context Closed #3337 reports a related ownership-command mismatch for Apktool shell launchers. This report concerns the separate recorded-crash optional debugger spawn and its deliberate Python-to-GDB exec; that path still retains Python as its expected command on current main. Open PR #1959 adds shared debugger session shutdown helpers and does not modify this optional stage or its command identity. No last known good version is established.

bsakaguchi closed this issue

2026-10-16 21:07:40 +00:00

bsakaguchi commented

2026-10-16 21:07:41 +00:00

Author

Owner

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

The ownership model breaks exactly where the launcher stops being itself: the stage deliberately execs GDB, so the cleanup path comparing against the stale Python command identity is validating the wrong process. Since the mapping context already documents that the provider owns both the launcher and the replaced debugger, the fix should update the ownership identity at exec time (or let cleanup match the configured debugger command), so cancellation can retire the live GDB and send the stop signal, preserving parent/process-group/run-token checks. The control removing only the stale expectation is good evidence the mismatch is the sole blocker.

@XinwangTao commented on GitHub (Oct 15, 2026): The ownership model breaks exactly where the launcher stops being itself: the stage deliberately execs GDB, so the cleanup path comparing against the stale Python command identity is validating the wrong process. Since the mapping context already documents that the provider owns both the launcher and the replaced debugger, the fix should update the ownership identity at exec time (or let cleanup match the configured debugger command), so cancellation can retire the live GDB and send the stop signal, preserving parent/process-group/run-token checks. The control removing only the stale expectation is good evidence the mismatch is the sole blocker.

bsakaguchi commented

2026-10-16 21:07:41 +00:00

Author

Owner

@yankikucuk commented on GitHub (Oct 15, 2026):

Working on this. Reproduced with your production-boundary test: cancellation during the debugger stage reported cleanup_incomplete with the command-identity mismatch and sent no signal. The debugger spawn now disables the command expectation across the launcher's exec (the basic decoder stage already does this), while parent, process-group and run-token ownership still gate the stop; the regression stops the live debugger with one SIGKILL and returns a plain cancellation, and a foreign-parent control is still refused. No real GDB was run. Draft PR follows shortly.

@yankikucuk commented on GitHub (Oct 15, 2026): Working on this. Reproduced with your production-boundary test: cancellation during the debugger stage reported cleanup_incomplete with the command-identity mismatch and sent no signal. The debugger spawn now disables the command expectation across the launcher's exec (the basic decoder stage already does this), while parent, process-group and run-token ownership still gate the stop; the regression stops the live debugger with one SIGKILL and returns a plain cancellation, and a foreign-parent control is still refused. No real GDB was run. Draft PR follows shortly.

bsakaguchi commented

2026-10-16 21:07:41 +00:00

Author

Owner

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

yankikucuk, disabling the command expectation across the launcher's exec matches the ownership reality — the stage process becomes GDB, so identity must follow the exec, while keeping parent/process-group/run-token checks as the stop gates preserves the safety model. The foreign-parent control staying refused is a good sign the fix is scoped correctly.

@XinwangTao commented on GitHub (Oct 16, 2026): yankikucuk, disabling the command expectation across the launcher's exec matches the ownership reality — the stage process becomes GDB, so identity must follow the exec, while keeping parent/process-group/run-token checks as the stop gates preserves the safety model. The foreign-parent control staying refused is a good sign the fix is scoped correctly.

bsakaguchi commented

2026-10-16 21:07:42 +00:00

Author

Owner

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

Confirmed the reported ownership mismatch on current Linux main (d72d856f5) with real GNU GDB 13.1 and pwndbg 2026.09.15, and opened #4435.

The fault probe loads the unchanged vendor entry through an authored initialization wrapper, pauses after Python has exec'd into native GDB, then cancels through the production recorded-crash adapter. The same recorded core (SHA-256 2a30f61376c50185308ccf899111d5b26e5f75da06e43da38a0dbf473997ccc8) was used before/after:

Observation	Base	#4435 head `0f3bd2e3d`
Returned code	`cleanup_incomplete`	`cancelled`
GDB alive when cancellation returned	yes	no
Basic partial evidence retained	yes	yes
Source core unchanged	yes	yes
Unrelated GDB-named control survived	yes	yes
Same-provider recovery	after releasing the paused fixture	immediately after completed cleanup

Base's nested cleanup cause explicitly compares observed /usr/bin/gdb … against the old Python expectation. The fix moves the exec-aware default into the shared decoder command owner, removing the basic-stage special case. Existing parent/group/run-token checks and explicit command pins remain. A real exec with a foreign token is still refused; files and retryable ownership remain retained.

Validation: 100 affected tests passed (1 existing skip), type/lint and docs checks passed. The unmodified public CLI/MCP verifier passed all 42 cases on both base and head, separately from the controlled fault probe. Full-workflow timing varied (82/149 s, sampled peak RSS 2.63/2.55 GiB); repeated controls are pending, so no performance conclusion is claimed yet. Other OSes and MCP SDK raw-partial recovery after cancellation are unverified.

Part of #4227. Raw local reports and measurements: /tmp/rea-4011-pwndbg-exec-20261016/.

@N0zoM1z0 commented on GitHub (Oct 16, 2026): Confirmed the reported ownership mismatch on current Linux main (`d72d856f5`) with **real GNU GDB 13.1 and pwndbg 2026.09.15**, and opened #4435. The fault probe loads the unchanged vendor entry through an authored initialization wrapper, pauses after Python has exec'd into native GDB, then cancels through the production recorded-crash adapter. The same recorded core (SHA-256 `2a30f61376c50185308ccf899111d5b26e5f75da06e43da38a0dbf473997ccc8`) was used before/after: | Observation | Base | #4435 head `0f3bd2e3d` | |---|---|---| | Returned code | `cleanup_incomplete` | `cancelled` | | GDB alive when cancellation returned | yes | no | | Basic partial evidence retained | yes | yes | | Source core unchanged | yes | yes | | Unrelated GDB-named control survived | yes | yes | | Same-provider recovery | after releasing the paused fixture | immediately after completed cleanup | Base's nested cleanup cause explicitly compares observed `/usr/bin/gdb …` against the old Python expectation. The fix moves the exec-aware default into the shared decoder command owner, removing the basic-stage special case. Existing parent/group/run-token checks and explicit command pins remain. A real exec with a foreign token is still refused; files and retryable ownership remain retained. Validation: 100 affected tests passed (1 existing skip), type/lint and docs checks passed. The unmodified public CLI/MCP verifier passed all 42 cases on both base and head, separately from the controlled fault probe. Full-workflow timing varied (82/149 s, sampled peak RSS 2.63/2.55 GiB); repeated controls are pending, so no performance conclusion is claimed yet. Other OSes and MCP SDK raw-partial recovery after cancellation are unverified. Part of #4227. Raw local reports and measurements: `/tmp/rea-4011-pwndbg-exec-20261016/`.

bsakaguchi referenced this issue

2026-10-17 21:01:31 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-17 21:12:39 +00:00

[PR #1595] [CLOSED] fix(dotnet): map managed RVAs through section virtual size #2994

bsakaguchi referenced this issue

2026-10-31 00:38:15 +00:00

[GH-ISSUE #5333] [Bug] inspect-go-binary returns build_info null when the PE data section has VirtualSize 0 #3242

bsakaguchi referenced this issue

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

[PR #1678] [MERGED] fix(native): bound PE resource RVAs by section virtual size #4747