fix(tui): GJC review sessions abort with small allocation failures despite available memory

[Yeachan-Heo]

Summary

Two consecutive tmux-resident GJC review sessions for PR #2722 aborted with signal 6 during early prompt/tool processing, despite abundant host memory and an unchanged clean worktree.

Observed

• GJC: v0.11.4 release build
• First session: aborted with signal 6 during deep-interview startup after prompt acceptance.
• Replacement session: aborted while inspecting basic repository state with memory allocation of 1048576 bytes failed.
• A separate PR fix(notifications): ignore stale session cwd warnings #2711 replacement session also recently aborted with memory allocation of 320000 bytes failed.
• Host memory at observation: 251 GiB total, about 186 GiB available; data-segment limit unlimited.
• Worktree remained clean; no repository mutation preceded either PR fix(subagent): surface resume failures instead of silently no-oping #2722 crash.

Expected

GJC should not abort on small allocations under ample available memory. If an internal arena/session-history bound is exhausted, it should fail closed with bounded diagnostics rather than terminating the tmux owner process.

Reproduction shape

1. Start a raw tmux-resident GJC session in a dedicated worktree.
2. Submit an exact-head PR review prompt invoking deep-interview/tool discovery.
3. Observe successful prompt acceptance and early tool activity.
4. Process aborts with signal 6 and a small allocation-failed message.

The affected PR review is now held instead of repeatedly restarting the crashing runtime.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

A second live GJC owner for issue #2736 aborted during repository mutation, confirming this is not limited to startup-only review sessions.

Evidence:

• session: gajae-code-issue-2736-handoff-command-r2
• pane owner PID: 70638
• tmux terminal: Pane is dead (signal 6, Mon Jul 20 12:31:17 2026)
• worktree remained intact with 5 modified files, +58/-3, on head 363632e88ebff637eb8c65fe6a58a28de0b02a0f
• host memory at observation: MemAvailable: 214135252 kB (~204 GiB), so host-wide memory exhaustion is not supported
• persistent tmux owner cgroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gjc-tmux-owner.service
• cgroup MemoryCurrent=224702926848 bytes across the long-lived shared owner service; MainPID=0

The session had progressed through production changes and was beginning tests when SIGABRT occurred. Recovery will preserve the dirty worktree and use a new tmux-resident owner. The shared-owner cgroup accounting/lifetime remains a likely diagnostic axis because many resident GJC/tmux descendants accumulate under the same service despite abundant host memory.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

A third live GJC session aborted with signal 6 during repository inspection, this time the recovered PR #2738 security-review owner.

Evidence:

• session: gajae-code-pr-2738-python-bridge-authority-r2
• pane PID: 550311
• terminal: Pane is dead (signal 6, Mon Jul 20 12:56:35 2026)
• worktree stayed clean on review branch; the owner was reading Python bridge executor/tool-bridge paths when it aborted
• host MemAvailable: 211377240 kB (~201 GiB)
• shared owner cgroup: /user.slice/user-1000.slice/user@1000.service/app.slice/gjc-tmux-owner.service
• cgroup MemoryCurrent=226199887872 bytes, MainPID=0

This is now reproduced across startup-only and active implementation/review workloads while host memory remains abundant. The common factor remains many GJC/tmux descendants accumulated in the shared persistent owner cgroup. The review will recover in a fresh tmux owner without changing the PR worktree.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Two additional live review owners aborted simultaneously with signal 6 at 2026-07-20 13:47:48 UTC:

• gajae-code-pr-2738-python-bridge-authority-r3, pane PID 1392486
• gajae-code-pr-2740-coordinator-team-routing, pane PID 1001599

Both worktrees remained clean at their exact review heads (07b2f831..., 4e838292...). Runtime evidence immediately after the dual abort:

• host MemAvailable: 203427172 kB (~194 GiB)
• shared cgroup /user.slice/user-1000.slice/user@1000.service/app.slice/gjc-tmux-owner.service
• MemoryCurrent=224037101568 bytes
• TasksCurrent=8149
• MainPID=0

The synchronized abort across unrelated code paths strengthens the shared persistent owner-cgroup / accumulated task-pressure hypothesis; this is not repository-test causality. Both reviews will recover in fresh tmux owners without modifying their clean worktrees.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Additional resource-path evidence from live issue #2736 implementation session (owner survived):

• session gajae-code-issue-2736-handoff-command-r3, owner PID 974694, stayed live
• child command bun test test/agent-session-openai-responses-replay.test.ts, PID 1902194
• repeated native panic text: memory allocation of 33554432 bytes failed
• child RSS grew from ~8.0 GiB to 10442740 KiB (~10.0 GiB) in ~83 seconds while multiple tests timed out
• host still reported ~196 GiB MemAvailable
• shared owner cgroup before termination: ~223.4 GB / ~8355 tasks; memory.max=max, memory.high=max, current memory.events shows oom 0, cumulative oom_kill 15
• therefore the current event is not proven to be a kernel/cgroup OOM kill; the cumulative OOM counter predates this run. It is a user-space/native allocation panic under severe shared-cgroup/process pressure.

A TUI Ctrl-C did not reach the child. I terminated only PID 1902194's process tree; GJC owner, clean worktree and five commits were preserved. Shared cgroup fell to 214935568384 bytes and 8102 tasks immediately afterward. The lane is instructed to stop package-wide/replay stress retries, run only changed-surface focused serial checks, and rely on hosted CI for broad validation.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Triage hold (internal owner lane): verified open and reproducible against current dev (294afc50). TUI small-allocation aborts in tmux review sessions are an owner-lane stability defect. This remains open with a durable hold — no external or additional mutation lane will be created while the repository is at its owner-lane cap and dev is terminal red (run 29952649477).

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Backlog red-team update: the accumulated evidence still proves repeated user-space/native allocation aborts under abundant host memory, but it does not isolate a GJC heap defect. The strongest common signal is the long-lived shared owner cgroup at ~214–226 GB and ~8k tasks; no current-event kernel/cgroup OOM kill was established. Treating host MemAvailable alone as exculpatory would be methodologically unsound because allocator address-space fragmentation, per-process/task pressure, and shared descendant lifetime remain unmeasured.

Repair/investigation contract remains internal and open:

1. reproduce the same workload in a fresh isolated owner cgroup and in the accumulated shared cgroup, recording per-process RSS/PSS, VMA count, thread/task count, cgroup memory/events, and allocator failure text;
2. identify the allocating process and stack (GJC owner vs Bun test child vs native addon) rather than attributing by tmux pane death;
3. cap/terminate leaked descendants and prove shared-cgroup task/memory returns to baseline after session disposal;
4. dogfood a release build through repeated review/resume/startup workloads and require zero SIGABRT plus bounded resident/task growth;
5. add a focused lifecycle regression for whichever descendant/resource leak is confirmed; do not add a fake catch/fallback for native allocation aborts.

No closure and no duplicate external lane.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Investigation update (pre-0.11.9 triage)

Read-only root-cause investigation completed against dev @ 87ac45b. Key conclusions:

Immediate mechanism: the memory allocation of N bytes failed text identifies a Rust allocator abort (native addon), which cannot be caught by JS try/catch — the native crash hook is panic-only (crates/pi-natives/src/crash.rs:13-29).

Ranked hypotheses:

1. Commit/address-space pressure from descendants accumulating under a long-lived shared owner cgroup (strongest; ~214-226 GB / ~8k tasks in the reported cgroup; two unrelated owners aborted simultaneously). Host MemAvailable does NOT rule out allocation denial — CommitLimit/Committed_AS, VMA counts, and vm.max_map_count were never captured.
2. Per-process native allocator fragmentation/VMA exhaustion (plausible; varying failure sizes across unrelated workloads support "next allocation failed").
3. TUI retained-memory leak (weakly supported — bounded render structures + JS-centric emergency compaction can't see native/cgroup pressure).
4. Fixed TUI buffer / configured Bun heap limit (little evidence).

Gaps found (fix targets):

• managed-owner-supervisor.ts:218-236 — SIGABRT receipts record provenance only; no RSS/PSS, VMA, threads, cgroup memory/tasks, or commit state. The supervisor survives the child abort and is the right observation boundary.
• tmux-owner-isolation.ts:354-372 — a safe existing tmux-server scope is reused indefinitely; per-review cleanup back to baseline is never proven.

Recommended path (not a speculative memory-behavior change): supervisor-side opt-in resource sampling persisted with the existing SIGABRT receipt + descendant/cgroup baseline-return assertions on session teardown; escalate to per-session scopes only if cleanup proof fails. A deterministic repro fixture does not exist yet and the failure is Linux/systemd-specific (not reproducible from macOS dev hosts).

[Yeachan-Heo]

Batch reconciliation (dev 9071343ec, Dev CI run 30183171548 terminal-red — no merges).

Disposition: admitted actionable but queued (investigation)

Reconfirmed open: prior investigation still points to native/Rust allocator aborts under long-lived shared owner cgroup pressure; no exact GJC heap defect isolated and no merged fix that retires the signal-6 / small-allocation abort class. Keep internal investigation contract. No mutation lane from this batch.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Current-dev classification — HOLD / ACTIONABLE INVESTIGATION

Audited against dev@590c4d2067aaf8db0bab893b102f9d6eda6ad2ef in the resident TUI/input subsystem batch.

The issue remains open and is not superseded. Current code has stronger cgroup classification, owner isolation, and a durable ManagedOwnerSigabrtReceipt, but the receipt still records process/owner provenance only; it does not capture the RSS/PSS, VMA count, thread/task count, cgroup memory/tasks/events, or commit-state measurements required to distinguish native allocator fragmentation from accumulated descendant/cgroup pressure. No deterministic fresh-vs-accumulated owner reproduction or teardown-to-baseline proof exists.

Disposition: retain the durable hold and the existing investigation contract. It is actionable only as instrumentation plus controlled reproduction, not as a speculative memory fallback or generic TUI patch. No mutation lane is admitted while the #3583 post-merge repair and #3570 owner feature are active.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Batch triage — ADMITTED ACTIONABLE INVESTIGATION / OWNER CONFIRMATION REQUIRED

Canonical baseline: dev@732856b3ccb3fade6e9fbc17908a4fbca5a7682f. Keep this open. The repeated signal-6 / small-allocation aborts are credible reliability incidents, but the evidence does not isolate a GJC heap defect, a kernel/cgroup OOM, or one native subsystem root cause. Host MemAvailable alone does not prove allocator/process/cgroup headroom.

Duplicate / overlap

• Not a duplicate of GJC session owner SIGABRT leaves durable workflow recovery and child-state coverage gap #2681/fix(tmux): recover durably after owner SIGABRT #2688: that line made SIGABRT owner-loss recovery durable; it does not prevent or diagnose the allocator abort.
• Not a duplicate of perf(session): managed legacy resume OOMs under a 6 GiB limit for a 27 MiB transcript #2834/fix: reduce managed legacy-resume memory amplification #2840: that was a deterministic, capped legacy-resume amplification path.
• Overlaps but is not superseded by fix(natives): fs_cache + ignore::walk integration causes unbounded native memory growth → OOM kill (v0.12.8) #3769 and merged fix(natives): bound filesystem scan collection #3780/fix(natives): resolve bounded scan edge cases #3796: filesystem scan collection/cache retention is now bounded, but the contract explicitly does not bound transient allocator footprint or process RSS and does not prove the historical fix(tui): GJC review sessions abort with small allocation failures despite available memory #2723 incidents came from fs_cache.

Hostile evidence gap

The current ManagedOwnerSigabrtReceipt (managed-owner-supervisor.ts:42-58) records generation/session/run identity, supervisor/child PIDs and start times, signal, exit code, and timestamp only. It does not capture crash-time RSS/PSS, VMA/thread/task counts, cgroup pressure/events, commit state, descendant census, or allocator/native backtrace. The general memory guard samples cgroup usage and selected worker RSS, but it is mitigation telemetry rather than an authoritative crash bundle.

Current owner path is internal runtime stability/managed-owner investigation, not an external mutation lane. Admission evidence for resolution must compare the same workload in a fresh isolated owner cgroup and the accumulated owner cgroup, then retain a bounded/redacted bundle containing: exact runtime/argv and cgroup membership; process tree; /proc RSS/PSS/VMA/thread data; cgroup memory.current/peak/events and pids/tasks counters; host CommitLimit/Committed_AS and vm.max_map_count; stderr plus core/backtrace where policy permits; and teardown-to-baseline proof.

Current dev CI is terminal red at run 30935832940: primary failure is shard 8, SDK operation inventory > accepts the committed generated matrix, because agent_session:registerToolSessionTransitionCleanup is an unclassified seam; evidence/aggregate then fail closed. This is unrelated to #2723 and prevents any green-current-dev claim.

—
Signed: Yeachan-Heo · GPT-heavy hostile batch triage · 2026-08-05

[Yeachan-Heo]

Hostile re-review — glm-deepseek lane · ADMITTED ACTIONABLE INVESTIGATION / OWNER_CONFIRMATION_REQUIRED

Continuing the prior GPT-heavy triage at canonical baseline dev@732856b3... (verified identical to live dev). Independent verification of the prior claims.

Independent verification

• Issue open, not superseded. ManagedOwnerSigabrtReceipt at packages/coding-agent/src/gjc-runtime/managed-owner-supervisor.ts:42-58 confirmed to record only: schema_version, generation, session_id, run_id, endpoint_incarnation, child_token, command_sha256, supervisor_pid, supervisor_start_time, child_pid, child_start_time, signal, signal_number, exit_code, received_at. No RSS/PSS, VMA/thread/task counts, cgroup memory/events, commit state, descendant census, or native backtrace. The prior triage's evidence-gap claim is accurate.
• dev CI terminal red at run 30935832940 confirmed: shard-8-of-8 SDK operation inventory > accepts the committed generated matrix failure (agent_session:registerToolSessionTransitionCleanup unclassified seam) → evidence producer fails closed → overall red. Unrelated to fix(tui): GJC review sessions abort with small allocation failures despite available memory #2723; precludes any green-current-dev claim.

Duplicate / overlap — confirmed

• Not GJC session owner SIGABRT leaves durable workflow recovery and child-state coverage gap #2681/fix(tmux): recover durably after owner SIGABRT #2688 (closed; SIGABRT owner-loss recovery, does not prevent/diagnose the allocator abort).
• Not perf(session): managed legacy resume OOMs under a 6 GiB limit for a 27 MiB transcript #2834/fix: reduce managed legacy-resume memory amplification #2840 (closed; deterministic capped legacy-resume amplification).
• Overlaps but not superseded by fix(natives): fs_cache + ignore::walk integration causes unbounded native memory growth → OOM kill (v0.12.8) #3769 (open) and merged fix(natives): bound filesystem scan collection #3780/fix(natives): resolve bounded scan edge cases #3796 (2026-08-03): filesystem scan collection/cache retention is now bounded, but the contract explicitly does not bound transient allocator footprint or process RSS and does not prove the historical fix(tui): GJC review sessions abort with small allocation failures despite available memory #2723 incidents came from fs_cache.

Disposition

Admitted as an actionable investigation, not an external mutation lane. The repair contract stands: compare the same workload in a fresh isolated owner cgroup vs the accumulated shared cgroup; capture a bounded/redacted crash bundle (exact runtime/argv + cgroup membership, process tree, /proc RSS/PSS/VMA/thread, cgroup memory.current/peak/events + pids/tasks, host CommitLimit/Committed_AS/vm.max_map_count, stderr + backtrace where permitted, teardown-to-baseline proof). Do not add a fake catch/fallback for native allocation aborts. No closure, no duplicate external lane.

—
Signed: Yeachan-Heo · glm-deepseek hostile re-review · 2026-08-05