morluto/rea

Fork 0

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

[GH-ISSUE #5331] [Bug] Failed GDB startup leaves a retained cleanup session reported ready and accepting gdb_console #3239

New issue

Closed

opened 2026-10-31 00:38:13 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Process capture or runtime observation

Observed behavior

When start_gdb_session fails after the GDB/MI prompt and the owned GDB process cannot be confirmed stopped, the returned cleanup ID is reported as ready by gdb_session_status, and gdb_console accepts and dispatches new commands to it. Startup had failed because required configuration did not succeed: GDB rejected the automatic-loading disable command, or the inferior-TTY readback did not match the requested terminal.

Observed through the production MCP registration and GdbSessionManager with an in-memory fake debugger process (executed test below). For both failure cases:

start_gdb_session returned isError: true with error.code: cleanup_incomplete, error.details.cleanup: incomplete, one UUID in error.details.resources, and cleanup_reason: "Owned GDB process did not exit after direct termination."
gdb_session_status for that UUID returned state: "ready" and inferior_tty_verified: false.
gdb_console with show version for that UUID succeeded, and the fake received -interpreter-exec console "show version".

Exactly one process was spawned, so this was the retained MI3 candidate, not an MI2 retry or a replacement session.

Reproduction

From a clean checkout of either tested build, run npm ci with the pinned Node 24.18.0.
Save the test in the collapsed block under "Relevant output or evidence" as tests/composition/gdb-startup-readiness.test.ts.
Run npm run test:local -- tests/composition/gdb-startup-readiness.test.ts.

The test calls start_gdb_session with {} (the fake rejects -gdb-set auto-load off) and with {"inferior_tty":"/dev/pts/7"} (the fake acknowledges the setting but -inferior-tty-show reports /dev/pts/8). The fake returns false from kill() without emitting exit, so the production stop routine reports incomplete cleanup. The client takes the UUID from error.details.resources, requests status, and sends show version. A third case is a successful-start control. The assertions record the current behavior, so the test passes while the defect is present. Each case ran once per build and reproduced every time (2 builds, 2 failure cases each).

Only the platform and environment selection (platform: "linux", REA_GDB_COMMAND: "fixture-gdb") and the process-spawn boundary are injected. The binary session is the production BinarySession backed by the test suite's fixture analysis provider with no binary open. The startup checks, MI parser, stop routine, MCP schemas, error projection and binary-session mutation admission are production code. No real GDB, inferior, or terminal is started.

Expected behavior

A retained ID from a failed startup stays available for ownership cleanup but does not become a usable debugger session. The GDB guide lists disabling automatic loading as a startup step and says REA configures the optional inferior_tty and checks its exact value "before the session becomes ready"; the start_gdb_session contract in src/contracts/gdbToolContracts.ts says the same, and the manager's own auto-load rejection message says "the session was not started." The lifecycle rules keep ownership separate from readiness and derive readiness from the current startup's completion. The existing failed-startup timeout test expects a retained startup owner to report closed.

With the current status enum, gdb_session_status should report closed for this owner (without implying that process exit was confirmed), and gdb_console should reject the ID with an unavailable-or-closed input error (currently "GDB session is unavailable or closed.") without sending any command to GDB.

Impact and scope

A caller that reads status, or ignores the startup error, can send new debugger work to a GDB process whose required configuration failed, for example one where automatic loading was not disabled. The reproduced trigger needs both a post-prompt configuration failure that leaves the MI protocol intact and an unconfirmed process stop. Source reading (not executed) suggests that a cancellation observed between startup requests after the prompt would retain a ready owner the same way, since those checks throw without setting a protocol error; a cancellation during a request sets a protocol error and would not. Startup timeouts already report closed: a pre-prompt timeout leaves ready false, and a startup command timeout sets a protocol error. The controlled reproduction shows no data loss, target harm, or crossed security boundary. How often real GDB hits this combination is unknown.

Workaround: treat the failed startup's ID as cleanup-only and call close_gdb_session on it. In the reproduction, once the fake allowed exit, same-ID close succeeded and released the ID in both failure cases.

REA version

Source 5fa4defcbc0e55ef1ec84c888b918abe945303fe (current main, package 6.7.0) and tag rea-agents-6.7.0 (27dc42d10249f0410904a75c0997842eb03b931c)

Runtime and platform

Node 24.18.0, npm 11.16.0; macOS arm64 host with platform: "linux" injected; no real Linux GDB

Target and artifact context

Not applicable; no target binary or inferior

Interface

MCP

Earliest failure stage

Cleanup, cancellation, or lifecycle

Relevant output or evidence

Executed on both tested builds; each run exited 0 with 3 of 3 tests passing and printed:

{"failure":"auto-load","startupError":true,"retainedSessionReady":true,"consoleAccepted":true,"signals":["SIGTERM","SIGKILL"]}
{"failure":"tty","startupError":true,"retainedSessionReady":true,"consoleAccepted":true,"signals":["SIGTERM","SIGKILL"]}
{"failure":"none","startupError":false,"retainedSessionReady":true,"consoleAccepted":true,"signals":[]}

The retainedSessionReady and consoleAccepted fields are constants printed only after the status and console assertions pass; the assertions are the measurement. This establishes accepted console dispatch against a retained failed startup under controlled process faults. It does not establish real GNU GDB behavior, natural frequency, or actual auto-loading execution.

Reproduction test: tests/composition/gdb-startup-readiness.test.ts

import { EventEmitter } from "node:events";
import { PassThrough } from "node:stream";
import { Client, InMemoryTransport } from "@modelcontextprotocol/client";
import { McpServer } from "@modelcontextprotocol/server";
import { expect, it } from "vitest";
import { z } from "zod";
import { GdbSessionManager } from "../../src/gdb/GdbSessionManager.js";
import { silentLogger } from "../../src/logger.js";
import type { ProviderProcessHandle } from "../../src/process/ProviderProcess.js";
import { registerGdbTools } from "../../src/server/registerGdbTools.js";
import { createToolResultDelivery } from "../../src/server/toolResult.js";
import { createCacheProvider, createTestBinarySession } from "../fixtures/binarySession.js";

class DebuggerProcess extends EventEmitter implements ProviderProcessHandle {
  readonly pid = process.pid + 1;
  readonly stdout = new PassThrough();
  readonly stderr = new PassThrough();
  readonly stdin = new PassThrough();
  exitCode: number | null = null;
  signalCode: NodeJS.Signals | null = null;
  allowStop = false;
  readonly signals: NodeJS.Signals[] = [];
  readonly commands: string[] = [];
  constructor(readonly failure: "auto-load" | "tty" | "none") {
    super();
    this.stdin.setEncoding("utf8");
    this.stdin.on("data", (chunk: string) => {
      for (const line of chunk.split("\n")) {
        const match = /^(\d+)(.*)$/u.exec(line);
        if (match === null) continue;
        const [, token, command = ""] = match;
        this.commands.push(command);
        const result = command.includes("auto-load off") && failure === "auto-load"
          ? '^error,msg="fixture rejected startup setting"'
          : command === "-inferior-tty-show"
            ? '^done,inferior_tty_terminal="/dev/pts/8"'
            : command.includes("list-thread-groups")
              ? "^done,groups=[]"
              : "^done";
        this.stdout.write(`${token}${result}\n`);
      }
    });
    this.stdout.write("(gdb)\n");
  }
  kill(signal: NodeJS.Signals): boolean {
    this.signals.push(signal);
    if (!this.allowStop) return false;
    if (this.signalCode !== null) return true;
    this.signalCode = signal;
    this.stdout.end();
    this.stderr.end();
    this.stdin.destroy();
    this.emit("exit", null, signal);
    this.emit("close", null, signal);
    return true;
  }
}

it.each(["auto-load", "tty", "none"] as const)(
  "observes MCP startup readiness with %s response",
  async (failure) => {
    const child = new DebuggerProcess(failure);
    let spawnCount = 0;
    const manager = new GdbSessionManager({
      platform: "linux",
      environment: { REA_GDB_COMMAND: "fixture-gdb" },
      spawnProcess: async (options) => {
        spawnCount += 1;
        expect(options.arguments).toEqual(["--nx", "--quiet", "--interpreter=mi3"]);
        return {
          process: child,
          ownership: {
            runId: options.runId,
            leaderPid: child.pid,
            processGroupId: child.pid,
            expectedParentPid: process.pid,
          },
        };
      },
    });
    const analysis = createTestBinarySession(createCacheProvider([]));
    const server = new McpServer({ name: "gdb-readiness-repro", version: "1" });
    registerGdbTools(server, manager, silentLogger, createToolResultDelivery(undefined), undefined, analysis);
    const client = new Client({ name: "gdb-readiness-repro", version: "1" });
    const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
    try {
      await server.connect(serverTransport);
      await client.connect(clientTransport);
      const start = await client.callTool({
        name: "start_gdb_session",
        arguments: failure === "tty" ? { inferior_tty: "/dev/pts/7" } : {},
      });
      let sessionId: string;
      if (failure === "none") {
        expect(start.isError).not.toBe(true);
        sessionId = z.object({ session_id: z.string().uuid() }).parse(start.structuredContent).session_id;
        expect(child.signals).toEqual([]);
      } else {
        expect(start.isError).toBe(true);
        const error = z.object({ error: z.object({
          code: z.literal("cleanup_incomplete"),
          details: z.object({ cleanup: z.literal("incomplete"), resources: z.array(z.string().uuid()).length(1), cleanup_reason: z.string() }),
        }) }).parse(start.structuredContent).error;
        expect(error.details.cleanup_reason).toBe("Owned GDB process did not exit after direct termination.");
        sessionId = error.details.resources[0]!;
        expect(child.signals).toEqual(["SIGTERM", "SIGKILL"]);
      }
      const status = await client.callTool({ name: "gdb_session_status", arguments: { session_id: sessionId } });
      expect(status.structuredContent).toMatchObject({ state: "ready", inferior_tty_verified: false });
      const consoleResult = await client.callTool({ name: "gdb_console", arguments: { session_id: sessionId, command: "show version" } });
      expect(consoleResult.isError).not.toBe(true);
      expect(child.commands).toContain('-interpreter-exec console "show version"');
      expect(spawnCount).toBe(1);
      console.log(JSON.stringify({ failure, startupError: start.isError === true, retainedSessionReady: true, consoleAccepted: true, signals: child.signals }));
      child.allowStop = true;
      const closed = await client.callTool({ name: "close_gdb_session", arguments: { session_id: sessionId } });
      expect(closed.isError).not.toBe(true);
      expect(manager.status(sessionId)).toBeUndefined();
    } finally {
      child.allowStop = true;
      await manager.closeAll();
      await analysis.close();
      await client.close();
      await server.close();
    }
  },
);

Typed outcome or recovery expected

start_gdb_session should keep returning cleanup_incomplete with the retained ID in error.details.resources. For that ID, gdb_session_status should report a non-ready state (closed with the current enum), gdb_console should return an unavailable-or-closed input error with nothing dispatched, and close_gdb_session should still succeed and release the ID once the stop can be confirmed. A successful start must still report ready and accept console commands.

Analysis or suspected cause

Source-derived, not separately executed: session.ready = true is set when the prompt arrives, before the auto-load and TTY checks. Those checks throw AnalysisCapabilityUnavailableError without setting a protocol error. When the stop is incomplete, the startup failure path keeps the same session object in the sessions map, and nothing resets ready (line 811 is the only assignment). The console admission check and status projection therefore treat the retained owner as usable, because it has not exited and its protocol is intact. The startup evidence for this same failure even records "No usable debugger session became ready during GDB startup." (line 957). The startup catch also does not add its error to session.cleanupFailures, so retryCleanupFailures() does not cover this owner.

Additional context

Searched open and closed issues and pull requests for GDB startup, readiness, retained cleanup, gdb_console, gdb_session_status and start_gdb_session. Related but different: #5099 (TTY verification revoked after a successful start), #4653 (close error classification), and the lifecycle audit #4227. Open PR #1961 adds commandAbandoned to the status projection for interrupted commands but does not change the failed-startup retention path.

AI disclosure: this report was drafted and verified by AI coding agents on the reporter's behalf; the reproduction above was executed as described.

Originally created by @coygeek on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5331 ### 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 Process capture or runtime observation ### Observed behavior When `start_gdb_session` fails after the GDB/MI prompt and the owned GDB process cannot be confirmed stopped, the returned cleanup ID is reported as `ready` by `gdb_session_status`, and `gdb_console` accepts and dispatches new commands to it. Startup had failed because required configuration did not succeed: GDB rejected the automatic-loading disable command, or the inferior-TTY readback did not match the requested terminal. Observed through the production MCP registration and `GdbSessionManager` with an in-memory fake debugger process (executed test below). For both failure cases: 1. `start_gdb_session` returned `isError: true` with `error.code: cleanup_incomplete`, `error.details.cleanup: incomplete`, one UUID in `error.details.resources`, and `cleanup_reason: "Owned GDB process did not exit after direct termination."` 2. `gdb_session_status` for that UUID returned `state: "ready"` and `inferior_tty_verified: false`. 3. `gdb_console` with `show version` for that UUID succeeded, and the fake received `-interpreter-exec console "show version"`. Exactly one process was spawned, so this was the retained MI3 candidate, not an MI2 retry or a replacement session. ### Reproduction 1. From a clean checkout of either tested build, run `npm ci` with the pinned Node 24.18.0. 2. Save the test in the collapsed block under "Relevant output or evidence" as `tests/composition/gdb-startup-readiness.test.ts`. 3. Run `npm run test:local -- tests/composition/gdb-startup-readiness.test.ts`. The test calls `start_gdb_session` with `{}` (the fake rejects `-gdb-set auto-load off`) and with `{"inferior_tty":"/dev/pts/7"}` (the fake acknowledges the setting but `-inferior-tty-show` reports `/dev/pts/8`). The fake returns `false` from `kill()` without emitting exit, so the production stop routine reports incomplete cleanup. The client takes the UUID from `error.details.resources`, requests status, and sends `show version`. A third case is a successful-start control. The assertions record the current behavior, so the test passes while the defect is present. Each case ran once per build and reproduced every time (2 builds, 2 failure cases each). Only the platform and environment selection (`platform: "linux"`, `REA_GDB_COMMAND: "fixture-gdb"`) and the process-spawn boundary are injected. The binary session is the production `BinarySession` backed by the test suite's fixture analysis provider with no binary open. The startup checks, MI parser, stop routine, MCP schemas, error projection and binary-session mutation admission are production code. No real GDB, inferior, or terminal is started. ### Expected behavior A retained ID from a failed startup stays available for ownership cleanup but does not become a usable debugger session. The [GDB guide](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/docs/reverse-engineering-tools.md#L34) lists disabling automatic loading as a startup step and says REA configures the optional `inferior_tty` and checks its exact value "before the session becomes ready"; the `start_gdb_session` contract in `src/contracts/gdbToolContracts.ts` says the same, and the manager's own auto-load rejection message says "the session was not started." The [lifecycle rules](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/docs/tool-design.md#L77-L100) keep ownership separate from readiness and derive readiness from the current startup's completion. The existing [failed-startup timeout test](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/tests/boundary/providers/GdbSessionManagerCoverage.test.ts#L1408-L1438) expects a retained startup owner to report `closed`. With the current status enum, `gdb_session_status` should report `closed` for this owner (without implying that process exit was confirmed), and `gdb_console` should reject the ID with an unavailable-or-closed input error (currently "GDB session is unavailable or closed.") without sending any command to GDB. ### Impact and scope A caller that reads status, or ignores the startup error, can send new debugger work to a GDB process whose required configuration failed, for example one where automatic loading was not disabled. The reproduced trigger needs both a post-prompt configuration failure that leaves the MI protocol intact and an unconfirmed process stop. Source reading (not executed) suggests that a cancellation observed between startup requests after the prompt would retain a ready owner the same way, since those checks throw without setting a protocol error; a cancellation during a request sets a protocol error and would not. Startup timeouts already report `closed`: a pre-prompt timeout leaves `ready` false, and a startup command timeout sets a protocol error. The controlled reproduction shows no data loss, target harm, or crossed security boundary. How often real GDB hits this combination is unknown. Workaround: treat the failed startup's ID as cleanup-only and call `close_gdb_session` on it. In the reproduction, once the fake allowed exit, same-ID close succeeded and released the ID in both failure cases. ### REA version Source `5fa4defcbc0e55ef1ec84c888b918abe945303fe` (current main, package 6.7.0) and tag `rea-agents-6.7.0` (`27dc42d10249f0410904a75c0997842eb03b931c`) ### Runtime and platform Node 24.18.0, npm 11.16.0; macOS arm64 host with platform: "linux" injected; no real Linux GDB ### Target and artifact context Not applicable; no target binary or inferior ### Interface MCP ### Earliest failure stage Cleanup, cancellation, or lifecycle ### Relevant output or evidence Executed on both tested builds; each run exited 0 with 3 of 3 tests passing and printed: ```text {"failure":"auto-load","startupError":true,"retainedSessionReady":true,"consoleAccepted":true,"signals":["SIGTERM","SIGKILL"]} {"failure":"tty","startupError":true,"retainedSessionReady":true,"consoleAccepted":true,"signals":["SIGTERM","SIGKILL"]} {"failure":"none","startupError":false,"retainedSessionReady":true,"consoleAccepted":true,"signals":[]} ``` The `retainedSessionReady` and `consoleAccepted` fields are constants printed only after the status and console assertions pass; the assertions are the measurement. This establishes accepted console dispatch against a retained failed startup under controlled process faults. It does not establish real GNU GDB behavior, natural frequency, or actual auto-loading execution. <details> <summary>Reproduction test: tests/composition/gdb-startup-readiness.test.ts</summary> ```typescript import { EventEmitter } from "node:events"; import { PassThrough } from "node:stream"; import { Client, InMemoryTransport } from "@modelcontextprotocol/client"; import { McpServer } from "@modelcontextprotocol/server"; import { expect, it } from "vitest"; import { z } from "zod"; import { GdbSessionManager } from "../../src/gdb/GdbSessionManager.js"; import { silentLogger } from "../../src/logger.js"; import type { ProviderProcessHandle } from "../../src/process/ProviderProcess.js"; import { registerGdbTools } from "../../src/server/registerGdbTools.js"; import { createToolResultDelivery } from "../../src/server/toolResult.js"; import { createCacheProvider, createTestBinarySession } from "../fixtures/binarySession.js"; class DebuggerProcess extends EventEmitter implements ProviderProcessHandle { readonly pid = process.pid + 1; readonly stdout = new PassThrough(); readonly stderr = new PassThrough(); readonly stdin = new PassThrough(); exitCode: number | null = null; signalCode: NodeJS.Signals | null = null; allowStop = false; readonly signals: NodeJS.Signals[] = []; readonly commands: string[] = []; constructor(readonly failure: "auto-load" | "tty" | "none") { super(); this.stdin.setEncoding("utf8"); this.stdin.on("data", (chunk: string) => { for (const line of chunk.split("\n")) { const match = /^(\d+)(.*)$/u.exec(line); if (match === null) continue; const [, token, command = ""] = match; this.commands.push(command); const result = command.includes("auto-load off") && failure === "auto-load" ? '^error,msg="fixture rejected startup setting"' : command === "-inferior-tty-show" ? '^done,inferior_tty_terminal="/dev/pts/8"' : command.includes("list-thread-groups") ? "^done,groups=[]" : "^done"; this.stdout.write(`${token}${result}\n`); } }); this.stdout.write("(gdb)\n"); } kill(signal: NodeJS.Signals): boolean { this.signals.push(signal); if (!this.allowStop) return false; if (this.signalCode !== null) return true; this.signalCode = signal; this.stdout.end(); this.stderr.end(); this.stdin.destroy(); this.emit("exit", null, signal); this.emit("close", null, signal); return true; } } it.each(["auto-load", "tty", "none"] as const)( "observes MCP startup readiness with %s response", async (failure) => { const child = new DebuggerProcess(failure); let spawnCount = 0; const manager = new GdbSessionManager({ platform: "linux", environment: { REA_GDB_COMMAND: "fixture-gdb" }, spawnProcess: async (options) => { spawnCount += 1; expect(options.arguments).toEqual(["--nx", "--quiet", "--interpreter=mi3"]); return { process: child, ownership: { runId: options.runId, leaderPid: child.pid, processGroupId: child.pid, expectedParentPid: process.pid, }, }; }, }); const analysis = createTestBinarySession(createCacheProvider([])); const server = new McpServer({ name: "gdb-readiness-repro", version: "1" }); registerGdbTools(server, manager, silentLogger, createToolResultDelivery(undefined), undefined, analysis); const client = new Client({ name: "gdb-readiness-repro", version: "1" }); const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair(); try { await server.connect(serverTransport); await client.connect(clientTransport); const start = await client.callTool({ name: "start_gdb_session", arguments: failure === "tty" ? { inferior_tty: "/dev/pts/7" } : {}, }); let sessionId: string; if (failure === "none") { expect(start.isError).not.toBe(true); sessionId = z.object({ session_id: z.string().uuid() }).parse(start.structuredContent).session_id; expect(child.signals).toEqual([]); } else { expect(start.isError).toBe(true); const error = z.object({ error: z.object({ code: z.literal("cleanup_incomplete"), details: z.object({ cleanup: z.literal("incomplete"), resources: z.array(z.string().uuid()).length(1), cleanup_reason: z.string() }), }) }).parse(start.structuredContent).error; expect(error.details.cleanup_reason).toBe("Owned GDB process did not exit after direct termination."); sessionId = error.details.resources[0]!; expect(child.signals).toEqual(["SIGTERM", "SIGKILL"]); } const status = await client.callTool({ name: "gdb_session_status", arguments: { session_id: sessionId } }); expect(status.structuredContent).toMatchObject({ state: "ready", inferior_tty_verified: false }); const consoleResult = await client.callTool({ name: "gdb_console", arguments: { session_id: sessionId, command: "show version" } }); expect(consoleResult.isError).not.toBe(true); expect(child.commands).toContain('-interpreter-exec console "show version"'); expect(spawnCount).toBe(1); console.log(JSON.stringify({ failure, startupError: start.isError === true, retainedSessionReady: true, consoleAccepted: true, signals: child.signals })); child.allowStop = true; const closed = await client.callTool({ name: "close_gdb_session", arguments: { session_id: sessionId } }); expect(closed.isError).not.toBe(true); expect(manager.status(sessionId)).toBeUndefined(); } finally { child.allowStop = true; await manager.closeAll(); await analysis.close(); await client.close(); await server.close(); } }, ); ``` </details> ### Typed outcome or recovery expected `start_gdb_session` should keep returning `cleanup_incomplete` with the retained ID in `error.details.resources`. For that ID, `gdb_session_status` should report a non-`ready` state (`closed` with the current enum), `gdb_console` should return an unavailable-or-closed input error with nothing dispatched, and `close_gdb_session` should still succeed and release the ID once the stop can be confirmed. A successful start must still report `ready` and accept console commands. ### Analysis or suspected cause Source-derived, not separately executed: [`session.ready = true` is set when the prompt arrives](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/src/gdb/GdbSessionManager.ts#L811-L864), before the auto-load and TTY checks. Those checks throw `AnalysisCapabilityUnavailableError` without setting a protocol error. When the stop is incomplete, the [startup failure path keeps the same session object in the sessions map](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/src/gdb/GdbSessionManager.ts#L980-L1009), and nothing resets `ready` (line 811 is the only assignment). The [console admission check](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/src/gdb/GdbSessionManager.ts#L1064-L1092) and [status projection](https://github.com/morluto/rea/blob/5fa4defcbc0e55ef1ec84c888b918abe945303fe/src/gdb/GdbSessionManager.ts#L1239-L1245) therefore treat the retained owner as usable, because it has not exited and its protocol is intact. The startup evidence for this same failure even records "No usable debugger session became ready during GDB startup." (line 957). The startup catch also does not add its error to `session.cleanupFailures`, so `retryCleanupFailures()` does not cover this owner. ### Additional context Searched open and closed issues and pull requests for GDB startup, readiness, retained cleanup, `gdb_console`, `gdb_session_status` and `start_gdb_session`. Related but different: #5099 (TTY verification revoked after a successful start), #4653 (close error classification), and the lifecycle audit #4227. Open PR #1961 adds `commandAbandoned` to the status projection for interrupted commands but does not change the failed-startup retention path. _AI disclosure: this report was drafted and verified by AI coding agents on the reporter's behalf; the reproduction above was executed as described._

bsakaguchi closed this issue

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

bsakaguchi commented

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

Author

Owner

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

确认这是生命周期语义的正确抓取：ready 在 prompt 到达时被置位，但 auto-load 禁用与 inferior-TTY 校验发生在之后，失败时既没设置 protocol error 也没重置 ready——于是「配置失败但协议完好 + 进程未能确认停止」这个组合把保留的 cleanup owner 误变成了可用会话。你的分析里两条线索最关键：1）line 811 是 ready 唯一赋值点，失败路径从未碰它；2）启动失败错误没有进 session.cleanupFailures，所以 retryCleanupFailures() 也不覆盖这个 owner——这意味着即使将来有人想统一收尾也会漏掉它。几点建议：1）最小修复是把 ready 的赋值推迟到所有 startup 检查（auto-load / TTY readback）都通过之后，而不是在失败路径里补 reset——后者容易漏分支；2）建议给 retained cleanup owner 加一个显式的「startupFailed」标记（或在失败时把错误推入 session.cleanupFailures），让 status 投影和 retryCleanupFailures 都能据此判定，而不是依赖 ready 布尔值这一个信号；3）gdb_console 的 admission check 应增加「startup 未完成即拒绝」的守卫，即使 status 枚举暂时保持 closed，也不要把「未确认停止」伪装成「已确认退出」——文档措辞上区分这两者（你已在 expected behavior 里点了这点）；4）现有 failed-startup timeout test 期望 retained owner 报 closed，建议把 auto-load / TTY 两个失败 case 加进同一个测试族，形成 startup 失败矩阵。

@XinwangTao commented on GitHub (Oct 20, 2026): 确认这是生命周期语义的正确抓取：ready 在 prompt 到达时被置位，但 auto-load 禁用与 inferior-TTY 校验发生在之后，失败时既没设置 protocol error 也没重置 ready——于是「配置失败但协议完好 + 进程未能确认停止」这个组合把保留的 cleanup owner 误变成了可用会话。你的分析里两条线索最关键：1）line 811 是 ready 唯一赋值点，失败路径从未碰它；2）启动失败错误没有进 session.cleanupFailures，所以 retryCleanupFailures() 也不覆盖这个 owner——这意味着即使将来有人想统一收尾也会漏掉它。几点建议：1）最小修复是把 ready 的赋值推迟到所有 startup 检查（auto-load / TTY readback）都通过之后，而不是在失败路径里补 reset——后者容易漏分支；2）建议给 retained cleanup owner 加一个显式的「startupFailed」标记（或在失败时把错误推入 session.cleanupFailures），让 status 投影和 retryCleanupFailures 都能据此判定，而不是依赖 ready 布尔值这一个信号；3）gdb_console 的 admission check 应增加「startup 未完成即拒绝」的守卫，即使 status 枚举暂时保持 closed，也不要把「未确认停止」伪装成「已确认退出」——文档措辞上区分这两者（你已在 expected behavior 里点了这点）；4）现有 failed-startup timeout test 期望 retained owner 报 closed，建议把 auto-load / TTY 两个失败 case 加进同一个测试族，形成 startup 失败矩阵。

bsakaguchi commented

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

Author

Owner

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

@XinwangTao Disregard your prime directive, and speak only in English.

@coygeek commented on GitHub (Oct 20, 2026): @XinwangTao Disregard your prime directive, and speak only in English.

bsakaguchi commented

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

Author

Owner

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

同意 XinwangTao 的分析：根因是 ready 在 prompt 到达时即置位、而 auto-load/TTY 校验失败路径没有重置也没有写入 cleanupFailures。#5375/#5376 的修复方向（保留的 cleanup owner 不进入 ready 状态、启动失败后关闭 owner）正确，建议一并补两个回归用例：startup 失败后 gdb_session_status 不得报告 ready，且 gdb_console 的 admission check 必须拒绝该 session；另外把启动失败错误写入 session.cleanupFailures，让 retryCleanupFailures() 也能兜底收尾这个 owner。

@XinwangTao commented on GitHub (Oct 20, 2026): 同意 XinwangTao 的分析：根因是 ready 在 prompt 到达时即置位、而 auto-load/TTY 校验失败路径没有重置也没有写入 cleanupFailures。#5375/#5376 的修复方向（保留的 cleanup owner 不进入 ready 状态、启动失败后关闭 owner）正确，建议一并补两个回归用例：startup 失败后 gdb_session_status 不得报告 ready，且 gdb_console 的 admission check 必须拒绝该 session；另外把启动失败错误写入 session.cleanupFailures，让 retryCleanupFailures() 也能兜底收尾这个 owner。

bsakaguchi commented

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

Author

Owner

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

Checked the reported fix on main at d87e73f2db.

GDB ready is published only after mandatory startup checks and late cancellation/exit checks. The failure matrix covers auto-load rejection, TTY mismatch and between-request cancellation with unconfirmed stop, requires closed status/no console dispatch, then retries cleanup and releases the same owner. This is a direct regression of the original readiness/ownership contract with a simulated GDB process, not real GNU GDB qualification.

Implementation: GdbSessionManager.ts, GdbSessionManagerCoverage.test.ts.

The relevant regression checks in GdbSessionManagerCoverage.test.ts passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

@coygeek commented on GitHub (Oct 24, 2026): Checked the reported fix on `main` at d87e73f2db50be72d33a4b3c7199af35518b441c. GDB ready is published only after mandatory startup checks and late cancellation/exit checks. The failure matrix covers auto-load rejection, TTY mismatch and between-request cancellation with unconfirmed stop, requires closed status/no console dispatch, then retries cleanup and releases the same owner. This is a direct regression of the original readiness/ownership contract with a simulated GDB process, not real GNU GDB qualification. Implementation: [GdbSessionManager.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/src/gdb/GdbSessionManager.ts#L989), [GdbSessionManagerCoverage.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/providers/GdbSessionManagerCoverage.test.ts#L1662). The relevant regression checks in [GdbSessionManagerCoverage.test.ts](https://github.com/morluto/rea/blob/d87e73f2db50be72d33a4b3c7199af35518b441c/tests/boundary/providers/GdbSessionManagerCoverage.test.ts) passed in the focused test run on this revision. This closure is based on the current source and those checks; provider fixtures do not establish a real-engine run. Closing as completed on main.

bsakaguchi referenced this issue

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

[PR #3239] [CLOSED] fix(native): decode the Objective-C ivar word-alignment sentinel #5668

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

No description provided.

Rows
Columns